Power Center Nomenclaturas

NOMENCLATURAS E MELHORES PRÁTICAS DE POWER CENTER
NOMENCLATURAS E MELHORES
PRÁTICAS DE POWER CENTER
Área:
Business Intelligence
14 de julho de 2011 Página 1 de 24
Índice
1. NOMENCLATURA DESENVOLVIMENTO.............................................................................. 3
1.1. NOMENCLATURA FOLDERS .............................................................................................. 3
1.2. NOMEMCLATURA MAPAS................................................................................................... 4
1.3. NOMENCLATURA SESSIONS ............................................................................................ 5
1.4. NOMENCLATURA WORKFLOW ........................................................................................ 6
1.5. NOMENCLATURA DE ARQUIVOS ................................................................................... 6
1.6. NOMENCLATURA DE LOGS E PATHS ........................................................................... 8
1.7. NOMENCLATURA DE CONEXÕES ................................................................................... 8
1.8. NOMENCLATURA DE SHORTCUTS ................................................................................ 8
1.9. USO DE VALORES DEFAULT ............................................................................................. 9
2. TRANSPORTE DE CÓDIGO ENTRE AMBIENTES .......................................................... 11
2.1. LABEL ......................................................................................................................................... 11
2.2. ASSOCIAÇÃO DOS OBJETOS ALTERADOS ............................................................. 11
2.3. APLICAÇÃO DE DEPLOY GROUP ................................................................................. 14
2.4. VERSIONAMENTO DE DEPLOY GROUP .................................................................... 14
3. CONEXÕES A BASE DE DADOS ............................................................................................. 15
4. MELHORES PRÁTICAS ............................................................................................................... 18
4.1. PREMISSAS ............................................................................................................................. 18
4.2. RECOMENDAÇÕES – CONSTRUÇÃO MAPAS.......................................................... 18
4.2.1. RECOMENDAÇÕES GERAIS PARA O DESENVOLVIMENTO .................... 18
4.2.2. SOURCES .......................................................................................................................... 19
4.2.3. TARGETS ........................................................................................................................... 20
4.2.4. LOOKUPS .......................................................................................................................... 20
4.2.5. FILTRO ............................................................................................................................... 21
4.2.6. AGREGATORS ................................................................................................................. 21
4.2.7. JOINERS............................................................................................................................ 22
4.2.8. SORT ................................................................................................................................... 22
4.2.9. MAPPLET ........................................................................................................................... 22
4.2.10. USO DE FLAT FILES .................................................................................................... 22
4.3. RECOMENDAÇÕES – CONSTRUÇÃO DE SESSIONS E WORKFLOW .......... 23

1. NOMENCLATURA DESENVOLVIMENTO
1.1. NOMENCLATURA FOLDERS
Os folders do repositório Power Center devem seguir o padrão:

<Nome do Modulo>_<Fonte Dados>
Exemplo:
Cobranca_Mobile, Cobranca_Ecob , Vendas_Sap...
O diretório com o sufixo Geral (exemplo: Cobranca_Geral) serve para transformações que utilizam
dados de mais uma fonte e para os processos de controle e criação do arquivo de parâmetro.
Atenção: A fonte de dados citada indica sempre o sistema transacional usado no processo.
Quando a origem for o próprio Datawarehouse o sufixo a ser utilizado é GERAL.
Exemplo:
Cobranca_Geral, Venda_Geral
OBJETOS REUTILIZÁVEIS
Objetos reutilizáveis como lookups, maplets, sources, targets e seguences são guardados em folders
com o sufixo fontes.
<Nome do Modulo>_<Fontes>
Exemplo:
Venda_Fontes
Atenção: Antes de alterar objetos compartilhados verificar todas as dependências que este objeto
pode ter.

1.2. NOMEMCLATURA MAPAS
Padrão de nomenclatura folders possui o seguinte formato :

“MAP_<Sigla do Modulo>_<Sequencial Mapa>_ <Sigla Função do Mapa> _<Descrição Mapa>”
• Sigla do modulo: Para os módulos já criados possuem a seguinte relação de siglas:

COB – Módulo de Cobrança
CLI – Modulo de Clientes
VND – Módulo de Vendas
TRF– Módulo de Trafego
REC– Módulo de Receita
DMT– Datamart de Clientes
DMC– Datamart de Churn
DMV– Datamart de VAS
• Sequencial Mapa
Seqüência numérica os mapas utilizam.
Durante a construção a forma mais fácil se saber qual a seqüência a ser usada é listar os
mapas no designer e usar o número seguinte ao ultimo.
• Sigla Função do Mapa:

EXT = Extração da fonte transacional.
RPL = Replica das informações do próprio DW ou DM.
STG = Qualquer tipo de transformação nos dados (agregações e integrações).
TRF = Outra variação para a identificação de mapas para a transformação.
Existem outros padrões que foram usados, mas que deixaram de fazer sentido quando foi
adotado um padrão único.
Siglas como FLT, ARQ, TRT, TRP que serão encontradas, porém, não devem ser usadas.
• Descrição do mapa:
Descrição breve do que faz o mapa, apenas o necessário para identificar a função do
processo.
Exemplo:
MAP_CLI_11223_STG_ASS_PLANO
Através da nomenclatura é possível conhecer a função do mapa.

Usando o exemplo, ele indica o mapa do módulo de clientes que transforma dados de plano do
assinante.
1.3. NOMENCLATURA SESSIONS
Regra da composição da nomenclatura de sessions.
“S_<Sequencial Da Session>_<Codigo Sistema de Origem>_<Codigo Sistema de Destino>_<Nome

do Mapa>”
• Sequencial Session
Identificador único da sessão.
Para novas sessões, sempre acrescentar mais um na ultima seqüência usada em produção.
• Código sistema origem

Os sistemas transacionais utilizados no Datawarehouse possuem códigos para sua
identificação.
Esta relação está armazenada na tabela DWH. BI_DIM_SISTEMA – instancia P00W1
Exemplos de sistemas:
5-Amdocs Mobile
20-ComTA
21-WPP
22-PS8
25-BI
27-BI RH
29-SAP
30-APRM
31-SCC
32-ERS
33-SETTLER
34-PA
• Código sistema destino

Mesmo domínio, serve para indicar para onde a informação será enviada.
• Nome do mapa
Nome do mapa vinculado a sessão.

Exemplo:
S_12163_025_000_MAP_CLI_11614_STG_TROCA_NUM_MOB
Sessão que utilize os dados do próprio Datawarehouse (indicado 025) para ambiente de
stage (indicado 000)
1.4. NOMENCLATURA WORKFLOW
O nome do workflow é composto pelas

WKF_<Sequencial do workflow>_<Cod do sist de Origem>_<Cod do sist de Destino>_ <Sigla Função
do workflow>_<Descrição breve workflow>
• Sequencial Workflow
Identificador único do Workflow.
Para novos workflows acrescentar mais um na ultima seqüencial utilizada na produção.
• Código sistema origem

Código de sistema que indica a origem dos dados
• Código sistema destino

Código de sistema que informa o destino dos dados
• Sigla Função do workflow

Semelhante com as siglas usadas nas nomenclaturas de mapas
EXT = Extração da fonte transacional.
RPL = Réplica das informações do próprio DW ou DM.
STG = Workflows que executam transformações nos dados
TRF = Também serve para identificar workflows que fazem transformações.
LDR= Workflow onde são feitas as cargas das tabelas.
Neste processo ficam as commands de PRE-LOAD, LOAD E POST LOAD. Maiores detalhes no
documento NOMENCLATURAS UNIX E SHELLS SCRIPTS.doc
• Descrição breve do workflow

Local destinado para pequenas descrições das funções do mapa
Exemplo:
WKF_40012_000_025_LDR_RETENCAO_DW
A nomenclatura demonstra que o Workflow que faz carga dos arquivos que estão em stage (000)
para o DW (025) para as tabelas de retenção
1.5. NOMENCLATURA DE ARQUIVOS
Existem dois tipos de arquivos texto nos processos de ETL, para cada tipo existe um padrão.
ARQUIVOS STAGE
Os arquivos de transformação, ou seja, arquivos intermediários que não representam o produto

final do ETL. Devem seguir o padrão:

“ff_<sigla do modulo>_<sigla_função_arquivo>_<descrição breve>.txt”
Exemplo:
ff_cli_ext_atend_aberto_base.txt
Regra de nomenclatura:
• Sigla do modulo: Siglas para módulos já criados:

COB – Módulo de Cobrança
CLI – Módulo de Clientes
VND – Módulo de Vendas
TRF– Módulo de Trafego
REC– Módulo de Receita
DMT– Datamart de Clientes
DMC– Datamart de Churn
DMV– Datamart de VAS
• Sigla Função do arquivo:

EXT = Arquivos de Extração da fonte transacional.
RPL =Arquivos de extrações de dados do próprio DW ou DM.
STG = Qualquer tipo de transformação nos dados (agregações e integrações).
TRF = Outra variação para a identificação de mapas para a transformação.
LKP= Para arquivos cuja função será somente para uso de lookup
JNR= Para arquivos cuja função será somente para uso de joiners
Os Arquivos de STAGE sempre utilizam letras minúsculas
Estes arquivos possuem uma função temporária e são utilizados apenas no momento do
processamento do ETL. Cada módulo possui um local próprio para depositar estes arquivos e são
identificados através do path /bi/STAGE/<módulo>
A relação de todos os módulos está no documento NOMENCLATURAS UNIX E SHELLS SCRIPTS.doc
ARQUIVOS LOADER
Os arquivos destinados para a carga das tabelas do modelo dimensional são escritos com letras
maiúsculas e nome do arquivo deve estar com o nome da tabela destino
Exemplo: BI_DIM_REGIONAL_VENDA.TXT
Arquivo de LOADER que será usado na carga da tabela BI_DIM_REGIONAL_VENDA
Para entidades com grandes volumes os arquivos podem ser divididos por regionais. Nestes casos a
regra apenas adiciona a sigla de regional no final do nome do arquivo.
Exemplo:
BI_DIM_ASSINANTE_RS.TXT
BI_DIM_ASSINANTE_PRSC.TXT

Arquivos com estas características ficam depositados diretório /bi/LOAD/FILE. Este local é
compartilhado e não há uma divisão por módulo.
1.6. NOMENCLATURA DE LOGS E PATHS
Os arquivos de logs devem possuir o mesmo nome do workflow apenas adicionando no final do
nome a extensão log
O mesmo deve ser feito com os logs das sessions.
Exemplos:
a) Logs do Workflow
Path: /bi/venda/work/WorkflowLogs/
Nome log : WKF_40009_022_000_INIC_CARGA_ATEND_DADOS.log
b) Logs das Sessions

Path: /bi/atendimento/work/SessLogs/
Nome log: S_40087_022_000_MAP_CLI_40050_RPL_SEGMENTACAO_PS8.log
Para os arquivos de BAD, o padrão é nome do arquivo que deveria ser gerado, porém, com o sufixo
BAD em vez de txt.
c) Arquivos de BAD Files

Path: /bi/atendimento/work/BadFiles/
Nome log: ff_stg_segmentacao_ps8.bad
Vale a pena reparar que o nome segue a mesma regra do arquivo a ser gerado no target
Nome do arquivo a ser gerado no target: ff_stg_segmentacao_ps8.txt
1.7. NOMENCLATURA DE CONEXÕES
As conexões devem ser criadas com o padrão descrito

ORA_<USUARIO>_<OWNER>_<INSTANCIA>
Exemplo:
ORA_PC_USER_DWH_P00DW1
O padrão indica que esta conexão utiliza o usuário PC_USER, para acessar tabelas do banco
P00DW1 pertencentes ao owner DWH.
1.8. NOMENCLATURA DE SHORTCUTS
Objetos reutilizáveis do ambiente design ficam reunidos no folder de sufixo FONTES.

Exemplo: Venda_Fontes, Aparelho_Fontes, Financeiro_Fontes
Geralmente os objetos destinados para este local são: Sources, Targets, Sequences e mapplets.
As definições envolvendo SOURCES devem ser criados em dois tipos subdiretórios: Flat files e
tabelas de banco.

Os nomes do source devem ter sempre o nome da entidade e os arquivos texto o nome do próprio
arquivo.
REGRA SOURCE
o ARQUIVOS TEXTO
SUB FOLDER: Flat_File
o TABELA BANCO
SUB FOLDER: Owner da tabela
Exemplo:
No exemplo, existem dois subfolders que identificam os owners onde os sources de tabelas estão,
DWH e P00CTA. Em ambos, os objetos são identificados pelo nome da entidade.
No caso de arquivos TXT basta colocá-los em FLAT_FILE, eles sempre são identificados com o prefixo
FF.
Para TARGETS não há subdivisão de diretórios.
Atenção: Ao usar o objeto fonte como shortcut, a ferramenta coloca automaticamente a palavra
“shotcut_to” junto com o nome da fonte.
Esta parte inicial deve ser desconsiderada.
Exemplo:
Automático Power Center:
Shortcut_to_DM_DIM_EMPRESA_ATENDIMENTO_FIN
Correto:
DM_DIM_EMPRESA_ATENDIMENTO_FIN
1.9. USO DE VALORES DEFAULT
Os valores default que são criados automaticamente durante a geração dos códigos não podem ser
usados.
Eles devem ser preenchidos com os paths correspondentes a localização de cada arquivo
Exemplos de valores default:

$PMTargetFileDir
$PMSourceFileDir
$PMCacheDir
$PMBadFileDir
$PMSessionLogDir
$PMWorkflowLogDir
No documento de NOMENCLATURAS UNIX E SHELLS SCRIPTS.doc possui toda estrutura de

diretórios por módulo que deve ser usada para o preenchimento destas informações.

2. TRANSPORTE DE CÓDIGO ENTRE AMBIENTES
2.1. LABEL
Todas as alterações devem ser feitas e agrupadas na LABEL correspondente ao projeto. Caso seja
encontrado problemas em outro ambiente que não seja desenvolvimento uma nova LABEL deverá
ser criada e o número da versão alterada.
Exemplo do procedimento:
A label gera o DEPLOY GROUP com os objetos desenvolvidos.
Exemplo:
lbl_OS65033_Aparelhos_v1
gera o deploy group
grp_OS65033_Aparelhos_v1
2.2. ASSOCIAÇÃO DOS OBJETOS ALTERADOS
No final da fase de testes unitários que dever ser realizados no ambiente de desenvolvimento, os
códigos modificados deve ser associados a label correspondente na ferramenta REPOSITORY
MANAGER.
Devem ser associados à label apenas a session que sofreu alteração. Desta forma se for alterado
apenas um mapa, deve ser levado somente a session referente a este mapa.
O Workflow só deve ser associado à label quando sofrer algum tipo de alteração.
Exemplo de associação da LABEL no REPOSITORY MANAGER
Passo 01 – Opção de Label no REPOSITORY MANAGER (Version>Apply Label)
Passo 02 – Seleção dos objetos afetados pelo projeto.

Apenas os objetos modificados devem ser relacionados, quando a alteração ocorre em
um mapa apenas levar a session correspondente a alteração, apenas quando for alterado
o corpo do workflow o mesmo deverá ser relacionado.
Não poderão ser aplicadas a label sessions que contenham conexões de uso pessoal
Ex: ORA_PROVISORIO_ARMANDO_D00DW1
As conexões utilizadas deverão ser as padrões do power Center.
Ex: ORA_PM_USER_PRD_P00DW1
Passo 03 – Associação do código a Label

Neste estágio devem ser indicados dados relativos ao projeto e LABEL que será responsável pelo
versionamento dos códigos Power Center.

A) Nome da label onde os objetos serão associados

Esta label só estará disponível após a solicitação para o CM da área de desenvolvimento.
Caso seja encontrados erros em outros ambientes, a label deverá ser versionada.
Exemplo:
lbl_OS65033_Aparelhos_Impacto
lbl_OS65033_Aparelhos_Impacto_v2
lbl_OS65033_Aparelhos_Impacto_v3
B) Comentários
Este campo serve para justificativa breve dos motivos da alteração e também deve ter o nome
do líder responsável e a data que associação está sendo feita.
Nomenclatura:
<Descrição breve das alterações> - <Nome do Líder> - <Nome da consultoria caso seja
necessário>(data da aplicação da label)
Exemplos:
o Mudanças na regra de optin – Paulo Moraes – Claro (02/06/2011)

o Evolução das parametrizações de ciclo de vida – Renato Silva – XY Consulting (30/05/2011)
C) Label All Children

Opção de extrema importância, ao indicá-la todos os objetos abaixo dela serão associados a
label. Assim a escolha dos códigos feita no passo 02
2.3. APLICAÇÃO DE DEPLOY GROUP
Após a associação dos objetos desenvolvidos a label, o deploy group deve ser aplicado ao
ambiente de testes, homologação e produção.
No desenho abaixo é representado o transporte do código entre os ambientes.
DESENVOLVIMENTO TESTES INTEGRADOS HOMOLOGAÇÃO PRODUÇÃO
ERRO
grp_OS65033_Aparelhos_v1 grp_OS65033_Aparelhos_v1
Caso seja encontrados problemas em quaisquer ambientes após desenvolvimento, as versões

anteriores devem ser RESTAURADAS e uma nova label criada.
PURGE DEPLOY GROUP
Purge (desfaz alterações) Purge (desfaz alterações)

grp_OS65033_Aparelhos_v1 grp_OS65033_Aparelhos_v1
ATENÇÃO: Ao encontrar erros, todos os ambientes afetados devem voltar a posição original antes
da aplicação do deploy.
Manter label com erro e sobrescrevê-la com nova versão não é recomendável.
2.4. VERSIONAMENTO DE DEPLOY GROUP
grp_OS65033_Aparelhos_v2 grp_OS65033_Aparelhos_v2 grp_OS65033_Aparelhos_v2
Com todos os problemas corrigidos, uma nova label deve ser solicitada.
Em seu titulo a versão deverá ser destacada.
Exemplo: lbl_OS65033_Aparelhos_v2 (label)
grp_OS65033_Aparelhos_v2 (deploy)
Após a entrada em produção os códigos deverão ter a mesma label em todo os ambientes

3. CONEXÕES A BASE DE DADOS
Com as novas premissas, uma estratégia muita utilizada terá que deixar de ser usada. Por motivos
diversos, os projetos sempre precisam mudar a conexão nos ambientes de testes ou homologação
(maioria das vezes para apontar para o ambiente de produção do próprio do DW ou do transacional
através de usuários pessoais).O problema é que não é possível realizar isto sem alterar a versão do
código e por conseqüência desvinculá-lo da label.
Para possibilitar a mudança sem prejudicar o versiomento, os acessos ao banco de dados serão
feitos através de variáveis de conexão.
O valor das variáveis pode ser configurado através arquivos de parâmetro preservando desta forma
código.
NOMENCLATURA DEFINIDA
Conexão original: ORA_PC_USER_PRD_P00DW1
Variável : $DBConnection_ORA_PC_USER_PRD_P00DW1
ATENÇÃO : A VARIAVEL NÃO FUNCIONA SEM O PREFIXO $DBCONNECTION EM SEU NOME
PADRÃO
$DBConnection_ < prefixo sempre obrigatório> + ORA_PC_USER_PRD_P00DW1 <nome da
conexão>
EXEMPLOS:
• $DBConnection_ORA_PC_USER_PRD_P00DW1 = Variável da conexão
ORA_PC_USER_PRD_P00DW1
• $DBConnection_ORA_PC_USER_PRD_P00CTA = Variável da conexão
ORA_PC_USER_PRD_P00CTA
• $DBConnection_ORA_PC_USER_PP2_P00PP2 = Variável da conexão
ORA_PC_USER_PP2_P00PP2

EXEMPLO DE COMO USAR:

1) Aponta na session a variável de conexão desejada
A variável de conexão fica definida na opção “USE CONNECTION VARIABLE”

2) Devem ser criados arquivos de parâmetro onde variável de conexão seja alimentada.
Estas conexões devem ser criadas no ambiente desejado.
Exemplo arquivos de parâmetro
[Operacional_Geral.WF:WKF_00004_000_025_LDR_OPERACIONAL]
$DBConnection_ORA_PC_USER_PRD_P00DW1 =ORA_PC_USER_USER_PRD_P00DW1 (conexão
existente)
[Operacional_Geral.WF:WKF_00001_000_025_EXT_META_VIEWS]
$DBConnection_ORA_PC_USER_PRD_P00DW1 =ORA_PC_USER_USER_PRD_H00DW1 (conexão
existente)
O arquivo de parâmetro pode referenciar o workflow todo ou apenas uma session. Este
apontamento é feito pelo cabeçalho do arquivo
Exemplo arquivos de parâmetro para session:
[Venda_SAP.WF:WKF_60100_029_000_STG_RPL_EXTRACOES_SAP.ST:S_60150_029_000_MAP_VN
D_60150_FLT_J_1BNFDOC]
$DBConnection_ORA_PC_USER_PRD_P00DW1 = ORA_PC_USER_STG_S00DW1 (conexão existente)

4. MELHORES PRÁTICAS
A intenção desta parte do documento é apresentar premissas e recomendações que garantam a

qualidade e o desempenho dos mapas.
4.1. PREMISSAS
ANTES DO INICIO DO DESENVOLVIMENTO:
A. Verificar o padrão de nomenclatura que será utilizado.

No caso de dúvidas, validar todas as nomenclaturas junto ao QA da Claro;
A numeração de mapas, sessions e workflows devem ser solicitados ao CM.
B. Montar um escopo dos nomes de processos, workflow, sessions, commands e scripts que
serem utilizados durante o projeto.
C. Verificar se os objetos que irão ser utilizados no projeto não estão alocados para outros
projetos e comparar os objetos de desenvolvimento estão com a mesma versão de
produção, para o desenvolvimento ocorra na versão do objeto correta.
4.2. RECOMENDAÇÕES – CONSTRUÇÃO MAPAS
4.2.1. RECOMENDAÇÕES GERAIS PARA O DESENVOLVIMENTO
o Use a pasta compartilhada para sources e targets

(Folders do repositório com sufixo “_fontes”)
o Trabalhar com arquivos texto
o Os arquivos textos são sempre delimitados por pipe “|”
o Reduza o número de transformações, sempre existe um custo quando se move dados entre
as transformações;
o Qualquer mapa com mais de 50 objetos é simplesmente muito grande e DEVE ser quebrado
em múltiplos mapas.
o Verifique a compatibilidade da data types dos bancos de dados com os do Informática Power
Center;
o Utilize transformações que reduzam o número de registros (filtros, agregações, etc...) no

início do processo;

o A utilização de Stored Procedures deixará o processo mais lento, pois o Power Center
precisará chamar a stored procedure para cada linha do processo;
o Operações numéricas são mais rápidas que operações com caracteres;
o Melhore o desempenho de comparações com caracteres utilizando, por exemplo, o

comando TRIM antes de comparar;
o Operadores são mais rápidos que funções, por exemplo, utilize || ao invés de CONCAT;
o Utilize sempre a variável SESSTARTIME em vez de SYSDATE;
o Desmarcar a opção OUTPUT das transformações quando a porta não for utilizada no
restante do processo. Para objetos que utilizam cache, todas as portas marcadas como
OUTPUT são armazenadas no arquivo de cache.
o Não deixar o mapa fazer conversão de datatype automaticamente, por exemplo, enviar um
valor numérico para um campo string. Utilize um TO_CHAR para converter o valor.
o Eliminar todas as ocorrências de Warning dos logs.
o Para grandes volumes o uso de “LookUps”, “Agregators”, “Joiners” deve estar com “Sorted
Input” .
o Utilize os locais para inserção de comentários e documente todos os objetos de

transformações e documente também cada transformação no Expression Transformation;
4.2.2. SOURCES
NOS CASOS DE EXTRAÇÃO DE DADOS VIA QUERY
o Procure não colocar queries complexas quando o acesso for do sistema transacional (colocar
somente com anuência do DBA).
o Caso a base não possua performance na leitura, troque o “where” do SQLOverride por um
filtro, deixando o “full scan”. Faça isso se a leitura em “full scan” for mais rápida que a leitura
com índices e se o volume dos dados lidos sem o filtro não forem grandes.
o Use o máximo de 4 a 8 “parallels”, o parallel pode consumir muito os recursos da base, se

você estiver utilizando o paralelismo do PowerCenter, procure não usar o da base de dados,
use os dois juntos em casos bem específicos.
USO DE SOURCES E SOURCE QUALIFIER
o Conecte apenas as portas que for utilizar principalmente no Source Qualifier;

o Caso não esteja disponível o source no folder que o projeto está sendo desenvolvido avisar o
CM, para que o mesmo disponha o source de forma correta no folder desejado.
o O desenvolvedor NÃO deverá fazer shortcuts de sources sem o consentimento do cm.
4.2.3. TARGETS
o O Update Strategy deve ser sempre a última transformação, ou seja, não deve existir
nenhuma transformação entre o Update Strategy e a tabela Target;
o Caso o mapa faça um update na tabela, utilize sempre a chave da tabela para fazer o update;
Observação: No ambiente da Claro utiliza-se update somente em tabelas de controle
4.2.4. LOOKUPS
o Antecipe o uso de Lookups compartilhadas.

o Caso precise fazer uma mesma Lookup (mesma tabela com a mesma comparação entre os
campos) mais de uma vez em um mesmo mapa, tente utilizar uma Lookup desconectada;
o Uso de Cache persistente
BASEADOS EM ARQUIVO TEXTO
o Em caso de TXT não utilize lookups cujo arquivo exceda o tamanho de 500 Mb, procure
utilizar o joiner.
o Utilize apenas os campos que serão usados no processo, em caso de txt coloque esses
campos nas primeiras posições, pois só assim poderá eliminá-los da “lookup”.
o No caso da lookup ser um “flat file”, deixe o “flat” organizado pelo índice lookup (prefira o
sort do Unix para ordenar o arquivo).
o Não usar campos “string” na chave da lookup quando a chave for composta com campos
numéricos.
o Use cache enable e procure garantir que há memória suficiente para lookup não ir para o
disco.
BASEADOS EM TABELAS
o Reduza o número de linhas da lookup com cláusula no Where do SQL Override.
o Aumente o desempenho de uma lookup colocando em primeiro as condições que tenham

sinal de igual.

o Use o índice da tabela para filtrar os registros e coloque “order by” na query (colocar
somente com anuência do DBA).
4.2.5. FILTRO
o Use o filtro no começo do mapa, o mais próximo possível do “Source Qualifier” para evitar o
trafego desnecessário de informações pelos mapas.
o Quando o fluxo possuir mais de uma condição baseada nos mesmos campos, utilize um
ROUTER, e utilize o grupo DEFAULT.
o Quando o fluxo possuir condições baseadas em campos diferentes, utilize FILTROS.
o Mantenha a condição do Filter simples, mova a expressão de condição complexa para

Expressions, quando o Filter está lento, normalmente é pela utilização direta de uma
condição complexa.
4.2.6. AGREGATORS
o Não use expressões complexas no “Agregator Expression”, especialmente nas portas do

GROUP BY.
o Procure trabalhar com dados tipo number nas colunas do GROUP BY.
o Use o “Sorted Input”.
o Caso o Banco de Dados seja Oracle, utilize UTL_SMTP package se desejar ser avisado por e-
mail quando os processos forem cancelados inesperadamente.
4.2.7. JOINERS
o Use o “Sorted Input”.
o Sempre defina a menor tabela como “master” na transformação Joiner entre duas tabelas.
Isso irá manter o cache com o menor número de registros possível.
o Use no joiner apenas as colunas que serão usadas no processo.
o Troque um Lookup por um Joiner sempre que estiver diante de um grande número de
registros a serem pesquisados.
4.2.8. SORT
o Procurar utilizar o “Sort” do Unix no lugar do “Sorter” do PowerCenter (para grandes

volumes). Consultar o documento NOMENCLATURAS UNIX E SHELLS SCRIPTS.doc para saber
qual script usar nesta operação.
4.2.9. MAPPLET
o Devido à dificuldade de manutenção evite usar Mapplets. O uso deste componente é

indicado somente se for comprovado a necessidade de reutilização de código em mais de
um mapa.
4.2.10. USO DE FLAT FILES
o Procure trabalhar com campos numéricos nas chaves.
o A precisão do PowerCenter é 28 dígitos, acima disso trate o campo como string.
o Não utilize arquivos muito grandes em lookups (> 500 Mb), neste caso utilize JOINER.
o Se o txt for utilizado com JOINER ou LOOKUP, ordene-o antes com o comando do Unix
“sort”, ele é melhor que o SORTER do PowerCenter. Cuidado para não tratar números como
strings (ex: -k 2n,2).
o Use o “Sorted Input” (para grandes volumes).

o Não utilize chaves compostas de busca da LOOKUP e do JOINER que contenham campos
strings e números.
o Nunca altere o tipo dos campos de busca. Se os campos da busca forem numéricos, devem
ser ordenados como numéricos.
o Não utilize delimitadores duplos.
o Utilize para campos string oriundos do relacional a função REPLACESTR em uma function
para retirar os caracteres que são usados como delimitadores.
o Onde for possível, alterar os dados de campo data para number, obedecendo ao formato
yyyymmdd
4.3. RECOMENDAÇÕES – CONSTRUÇÃO DE SESSIONS E WORKFLOW
o Colocar ‘Fail parent if this task fails” e “Fail parent if this task does not run” em Comands e
Sessions – Ao selecionar está opção, o Integration Service do Power Center para de rodar o
comando executado apresenta algum erro, sem isto o processo irá rodar até o final mesmo
tendo falha.
Exemplo:

o Os links de workflows devem possuir controle de consistência (PrevTaskStatus) com valor de

Succeeded
Exemplo :
SESSIONS
o O parâmetro do TRACING LEVEL da session deve estar sempre configurado para TERSE.
o O parâmetro do COMMIT INTERVAL da session deve estar próximo ao valor de linhas que
serão escritas no arquivo destino.
o Definir valor de Parâmetros de DTM buffer size = 100000000 e Default buffer block size =
2000000.
ATENÇÃO:
o Todas as sessions devem criadas como reutilizáveis, esta procedimento é fundamental para
que o DEPLOY GROUP funcione apenas para os objetos alterados.
Exemplo: Na aba de EDIT TASK da SESSION marcar como reutilizável

Power Center Nomenclaturas

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Power Center Nomenclaturas

Enviado por

Direitos autorais:

Formatos disponíveis

NOMENCLATURAS E MELHORES PRÁTICAS DE POWER CENTER

14 de julho de 2011 Página 2 de 24

1.1. NOMENCLATURA FOLDERS

Os folders do repositório Power Center devem seguir o padrão:

14 de julho de 2011 Página 3 de 24

1.2. NOMEMCLATURA MAPAS

Padrão de nomenclatura folders possui o seguinte formato :

• Sigla do modulo: Para os módulos já criados possuem a seguinte relação de siglas:

• Sigla Função do Mapa:

Através da nomenclatura é possível conhecer a função do mapa.

1.3. NOMENCLATURA SESSIONS

Regra da composição da nomenclatura de sessions.

“S_<Sequencial Da Session>_<Codigo Sistema de Origem>_<Codigo Sistema de Destino>_<Nome

• Código sistema origem

• Código sistema destino

14 de julho de 2011 Página 5 de 24

1.4. NOMENCLATURA WORKFLOW

O nome do workflow é composto pelas

• Código sistema origem

• Código sistema destino

• Sigla Função do workflow

• Descrição breve do workflow

1.5. NOMENCLATURA DE ARQUIVOS

Os arquivos de transformação, ou seja, arquivos intermediários que não representam o produto

14 de julho de 2011 Página 6 de 24

“ff_<sigla do modulo>_<sigla_função_arquivo>_<descrição breve>.txt”

• Sigla do modulo: Siglas para módulos já criados:

• Sigla Função do arquivo:

Os Arquivos de STAGE sempre utilizam letras minúsculas

A relação de todos os módulos está no documento NOMENCLATURAS UNIX E SHELLS SCRIPTS.doc

14 de julho de 2011 Página 7 de 24

1.6. NOMENCLATURA DE LOGS E PATHS

b) Logs das Sessions

c) Arquivos de BAD Files

1.7. NOMENCLATURA DE CONEXÕES

As conexões devem ser criadas com o padrão descrito

1.8. NOMENCLATURA DE SHORTCUTS

Objetos reutilizáveis do ambiente design ficam reunidos no folder de sufixo FONTES.

14 de julho de 2011 Página 8 de 24

Para TARGETS não há subdivisão de diretórios.

1.9. USO DE VALORES DEFAULT

Exemplos de valores default:

No documento de NOMENCLATURAS UNIX E SHELLS SCRIPTS.doc possui toda estrutura de

14 de julho de 2011 Página 10 de 24

2. TRANSPORTE DE CÓDIGO ENTRE AMBIENTES

2.2. ASSOCIAÇÃO DOS OBJETOS ALTERADOS

Exemplo de associação da LABEL no REPOSITORY MANAGER

Passo 01 – Opção de Label no REPOSITORY MANAGER (Version>Apply Label)

Passo 02 – Seleção dos objetos afetados pelo projeto.

Passo 03 – Associação do código a Label

14 de julho de 2011 Página 12 de 24

A) Nome da label onde os objetos serão associados

o Mudanças na regra de optin – Paulo Moraes – Claro (02/06/2011)

C) Label All Children

2.3. APLICAÇÃO DE DEPLOY GROUP

No desenho abaixo é representado o transporte do código entre os ambientes.

DESENVOLVIMENTO TESTES INTEGRADOS HOMOLOGAÇÃO PRODUÇÃO

Caso seja encontrados problemas em quaisquer ambientes após desenvolvimento, as versões

PURGE DEPLOY GROUP

DESENVOLVIMENTO TESTES INTEGRADOS HOMOLOGAÇÃO PRODUÇÃO

Purge (desfaz alterações) Purge (desfaz alterações)

2.4. VERSIONAMENTO DE DEPLOY GROUP

DESENVOLVIMENTO TESTES INTEGRADOS HOMOLOGAÇÃO PRODUÇÃO