Padrões de Desenvolvimento SIN

SI - Informações de Negócios
Padrões de desenvolvimento SIN

Documentação técnica
Versão 1.0
*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Versão 1.0 – Última Atualização em: 2/4/2019 5:33 AM – Atualizado por: smagalhaes@globosat.com.br
Histórico de Alterações no Documento
Versão Data Atividade Responsável

0.1 17/08/2015 Versão inicial do documento Sergio Magalhães
0.2 09/11/2015 Inclusão do procedimento de Atualização (refresh) das Views Materializadas Raphael Vale
0.3 22/02/2015 Detalhamento de uso da TabelaApoio Sergio Magalhães
0.4 01/03/2016 Inclusão de regras de nomenclatura de objetos no DS Sergio Magalhães
0.5 09/08/2016 Inclusão de regras para desenvolvimento de dashboard Sergio Magalhães
0.5 17/11/2016 Inclusão de regras de AK Sergio Magalhães
0.6 06/12/2016 Inclusão de regras de relatórios Sergio Magalhães
0.7 13/12/2018 Inclusão de regras de nomenclatura entidades/tabelas em DataLake Cristiano Gentil
Elaborado por: Revisado por: Homologado por: Impresso em:

Sergio Magalhães Sergio Magalhães André Oliva 4/2/2019 - 05:33 Pág.: 2/26


Sumário
Histórico de Alterações no Documento ............................................................................................................. 2
Identificação do documento............................................................................................................................. 5
Objetivos do Documento – Padrões de desenvolvimento ............................................................ 5
Audiência ...................................................................................................................... 5
Padrão para Modelagem de Dados .................................................................................................................. 6
Modelo ErWin................................................................................................................. 6
Esquemas Oracle............................................................................................................. 6
Tabelas e Views ............................................................................................................. 6
Colunas ........................................................................................................................ 7
Índices ......................................................................................................................... 7
Tabela Apoio ................................................................................................................. 7
Identificadores alternativos .............................................................................................. 8
Desenvolvimento de Relatórios ........................................................................................................................ 9
Padrão tabelas e gráficos ................................................................................................. 9
Fonte ........................................................................................................................... 9
Cores ........................................................................................................................... 9
Bordas, fundos e contornos ............................................................................................. 10
Página de estilo ............................................................................................................ 10
Cabeçalho ................................................................................................................... 10
Rodapé ....................................................................................................................... 11
Corpo do relatório ........................................................................................................ 11
Formatação de página ................................................................................................... 13
Controle de versão de relatórios ....................................................................................... 13
Detalhamento de procedimentos ....................................................................................... 15
Desenvolvimento de dashboard ..................................................................................................................... 15
Cabeçalho ................................................................................................................... 15
Caixa de filtros ............................................................................................................ 15
Rodapé ....................................................................................................................... 16
Padrão de cores ............................................................................................................ 16


Divisão da tela ............................................................................................................. 16

Seleções de hierarquia em gráficos.................................................................................... 17
Limitação de tela .......................................................................................................... 17
Visibilidade ................................................................................................................. 18
Compatibilidade ........................................................................................................... 19
Usabilidade ................................................................................................................. 19
Desenvolvimento em SAP Data Service .......................................................................................................... 20
Objetos básicos utilizados no Desenvolvimento .................................................................... 20
Padrões de Nomenclatura ............................................................................................... 20
Atualização (refresh) das Views Materializadas ................................................................... 22
Carga na área de Stage .................................................................................................. 23
Carga no Relacional ....................................................................................................... 23
Valores Default de Chaves............................................................................................... 24
Carga no Dimensional ..................................................................................................... 24
Camada Semântica ........................................................................................................ 25
Política de atualização e retenção .................................................................................... 25
Convenções, Termos e Abreviações ................................................................................................................ 26



Identificação do documento
Objetivos do Documento – Padrões de desenvolvimento
Padronizar os procedimentos de desenvolvimento de soluções da Gerência de Sistemas de Inteligência de Negócios.
Audiência
Este documento destina-se a todos envolvidos no ciclo de vida de desenvolvimento de soluções SIN.



Padrão para Modelagem de Dados

Os modelos de dados do SIN deverão ser mantidos atualizados em arquivo padrão ErWin, seguindo a seguinte
padronização e práticas descritas a seguir.
Modelo ErWin
Os conjuntos de dados que façam sentido devem ser separados em SAs (Subjects Areas) no ErWin para melhor leitura do
modelo de dados. A princípio não teremos o modelo de dados lógico, somente o físico. As tabelas devem ser criadas em
maiúscula no banco de dados.
Esquemas Oracle
Devemos ter 3 esquemas para cada camada dos dados:
Camada Nome
Stage PrdStg
Relacional PrdRel
Dimensional PrdDim
As tabelas de trabalho (work) devem ficar no esquema referente a tabela carregada no destino.
Tabelas e Views
O nome da tabela não deverá usar underscore para separar as palavras. Para facilitar a leitura deve ser utilizado o padrão
de escrita maiúsculo e minúsculo.
Exemplos: PessoaBase, PessoaJuridica etc.
Prefixos indicativos
Será padronizado o prefixo de alguns tipos de tabelas:
Tipo Prefixo Exemplo
View vw vwCanal
Fatos Primárias ft ftInsercao
Fatos Agregadas fa faInsercao
Dimensões dm dmCanal
Stage stg stgContrato
Trabalho wk wkhsInsercao
Histórica hs hsInsercao
Tradutoras tr trAbrangenciaComercialEvento
Controle ct ctUsuarioBIG
Raw Data ( dados coletados ) rw rwConsumoSimulcastHorizon
Trusted Zone ( dados tratados ) tr trConsumoSimulcastHorizon
Refined Zone ( dados refinados ) rf rfConsumoSimulcastHorizon



Colunas
O nome das colunas também não deverá ser separado por underscore. Para facilitar a leitura deve ser utilizado o padrão de
escrita maiúsculo e minúsculo. Os campos devem ser criados com maiúscula no banco de dados.
Exemplos: cdPessoaBase, dsObservacaoCadastro etc
Prefixos indicativos
Será padronizado o prefixo de todos os tipos de colunas:
Tipo Prefixo Exemplo
Identificador ID idSituacaoInsercao
Data DT dtAlteracao
Indicador IN inImpactaFaturamento
Valor VL vlLiquidoAgencia
Descrição DS dsAbrangencia
Quantidade QT qtMinuto
Percentual PC pcAlcance
Código CD cdOperSistOrig
Número NR nrVersaoPlanoVenda
Nome NM nmCanal
Sigla SG sgProducao
Time Stamp TS tsCarga
Partição PT ptAno
Índices
Para garantir a unicidade do modelo, serão criados índices primários únicos que tipicamente também servirão para acesso
aos dados. Também devem ser criadas as Alternate Key nas tabelas, em geral sobre o campo cdOperSistOrig.
Tabela Apoio
Para registrar listas pequenas como estado, tipos de cliente, tipos de RP etc., criaremos uma tabela específica, chamada
TabelaApoio, para registrar os dados e evitarmos uma poluição de tabelas com 3 a 30 linhas desnecessariamente.
No modelo, todos os relacionamentos com TabelaApoio devem ser nomeados. A leitura do modelo ficaria, por exemplo,
Apoio “identifica o tipo de cliente de” Pessoa.
Nomes e descritivos na maior parte das vezes estarão em tabelas próprias ou na TabelaApoio para que todo e qualquer
tipo seja referenciados por um identificador e não por uma sigla.
A cada novo tipo de TabelaApoio deve ser criada a view correspondente no ambiente relacional. Como exemplo, temos a
vwSituacaoInsercao.



Identificadores alternativos
Para que não seja necessário criar “outers join” entre as tabelas, devem ser usados identificadores alternativos. Esses
registros deverão ser criados para que toda linha possua uma linha de referência na Foreign Key.
O uso de joins diretos (inner join) otimiza o acesso aos dados, visando o o desempenho das aplicações.
Exemplo de chaves sem referência:

Id Descrição Observação
-1 Não Identificado Usado quando o processo de carga não consegue encontrar a chave do Relacional
correspondente para uma chave vinda do transacional
-2 Não Definido Nulo na Origem
-3 Múltiplos Valores Quando a informação de um registro “pai” é gerada pela análise dos valores dos registros
“filhos” e que não possuem um único valor. Por exemplo o Setor Econômico de uma
Holding sendo gerado pelo Setor Econômico das diversas empresas subordinadas.
-4 Não Aplicável O atributo não se aplica para o registro. Por exemplo segmento de mercado para
contatos.
-5 Previsão Quando o registro é gerado por processos preditivos.



Desenvolvimento de Relatórios
Padrão tabelas e gráficos
As diretrizes abaixo devem ser adotadas para padronização dos gráficos e tabelas de todos os materiais do SIN, em
harmonia com os novos layouts propostos para as apresentações internas e externas, garantindo melhor visualização e
leitura. Evitar o uso de infográficos tridimensionais (3D), trabalhar preferencialmente de forma plana.
Fonte
Utilizar somente a fonte Arial e suas variações (regular, bold, italic). O corpo/tamanho da fonte varia de acordo com o
tamanho da tabela ou gráfico, preservando uma boa leitura no chart em todas as suas formas de visualização (monitores
de tamanhos variados, projeção/slideshow, impressão). Dividir o conteúdo em mais de uma aba quando necessário.
Cores
Não utilizar as cores padrão do SAP BO, utilizar o CSS padrão com a paleta de cores sugeridas a seguir, mais modernas e
com melhor contraste.



Azul RGB(59,107,157)
Amarelo RGB(237,175,76)
Verde RGB(110,163,90)
Vermelho RGB(202,65,61)
Roxo RGB(131,81,139)
Cinza RGB(142,145,144)
Azul Claro RGB(85,174,215)
Laranja RGB(222,106,12)
Verde Escuro RGB(68,116,84)
Marrom RGB(132,71,71)
Roxo RGB(47,42,156)
Cinza Escuro RGB(93,93,94)
Esta ordem acima é a de preferência, ou seja, se a tabela tiver apenas uma cor aplicada, esta cor deve ser o azul, se tiver
duas, azul e amarelo, e assim por diante.
Bordas, fundos e contornos

Eliminar todas as linhas, contornos e outros elementos desnecessários da tabela/gráfico para que ela fique mais limpa e
tenha melhor aspecto visual, seguindo os exemplos acima para os gráficos tipo pizza e colunas/barras, e as imagens abaixo
para as tabelas.
Página de estilo
Utilizar a página de estilo abaixo como padrão.
Globosat.css
Cabeçalho
Os relatórios devem conter cabeçalho com a imagem boimg://topo_landscape.png ou boimg://topo_portrait.png, caso o
relatório tenha orientação Paisagem ou Retrato, respectivamente. Deve conter também o nome do relatório, usando a
função =NomeDocumento() do BO. Agregar o nome da aba ao título, caso necessário.



Rodapé
Os relatórios devem conter um rodapé com as seguintes informações:
Nome do relatório (função =NomeDocumento()), Data de Referência (campo Data de Última Carga – Fato), Data de
Impressão (função =DataAtual()), Observações (preencher com as principais restrições aplicadas nas consultas do
relatório), Nome do usuário (função =UsuárioAtual()), Página (função =Página()+" de " +NúmeroDePáginas())
Corpo do relatório
Quando necessário haver quebra ou descrição do assunto no relatório, usar fonte Arial, 13, bold, RGB (51,51,51), alinhado
à esquerda do relatório, como abaixo:



As tabelas abaixo devem seguir o seguinte alinhamento:



Formatação de página
Os relatórios devem ser formatados para terem as seguintes medidas:
Controle de versão de relatórios

Relatório novo com mudança de universo
Alterar o universo em desenvolvimento
Desenvolver o relatório no ambiente de desenvolvimento (rj2k8bid04) na pasta SIN\Desenvolvimento
Nomenclatura do relatório: <yyyymmdd> - <Nome do relatório> - v<versão>
Onde: <yyyymmdd> é a data de criação do relatório ou versão
<versão> número da versão na data
Testar em desenvolvimento com regressão do impacto em outros relatórios pela alteração no universo
Se pronto para teste de sistemas ou usuário, solicitar a migração do relatório e universo para o ambiente de
produção, na pasta SIN\Homologação, ainda com os indicadores de data e versão
Testar em produção com regressão do impacto em outros relatórios pela alteração no universo
Criar o relatório nas tabelas de controle para acesso dos usuários de homologação
Estando ok para produção, solicitar a alteração do nome para retirada dos indicadores de versão e mudança de
pasta para a pasta _BI Relatórios\Relatórios BI
Relatório novo sem mudança de universo

Desenvolver o relatório no ambiente de produção na pasta SIN\Desenvolvimento


Testar o relatório em produção

Se pronto para teste de sistemas ou usuário, copiar o relatório para a pasta SIN\Homologação, ainda com os
indicadores de data e versão
Criar o relatório nas tabelas de controle para acesso dos usuários de homologação
Estando ok para produção, solicitar a alteração do nome e mudança de pasta para a pasta de produção
Alteração de relatório com mudança de universo

Alterar o universo em desenvolvimento
Copiar o relatório da pasta _BI Relatórios\Relatórios BI para pasta SIN\Desenvolvimento em desenvolvimento. Em
caso de dúvida se o objeto a ser alterado pode estar desatualizado com a produção, copiar de produção
Alterar o relatório no ambiente de desenvolvimento (rj2k8bid04) na pasta SIN\Desenvolvimento
Testar em desenvolvimento com regressão do impacto em outros relatórios pela alteração no universo
Se pronto para teste de sistemas ou usuário, solicitar a migração do relatório e universo para o ambiente de
produção, para a pasta SIN\Homologação, ainda com os indicadores de data e versão
Testar em produção com regressão do impacto em outros relatórios pela alteração no universo
Criar um link do relatório para a pasta particular do usuário que irá testar e orientar sobre como acessar o relatório
Estando ok para produção:
Copiar o relatório original da pasta _BI Relatórios\Relatórios BI para a pasta SIN\Versões Antigas
acrescentando o prefixo <yyyymmdd>
Solicitar que o relatório homologado seja copiado, sobreescrevendo o relatório anterior e retirar o
prefixo <yyyymmdd>
Alteração de relatório sem mudança de universo

Copiar o relatório da pasta _BI Relatórios\Relatórios BI para pasta SIN\Desenvolvimento em produção
Alterar o relatório na pasta SIN\Desenvolvimento
Testar o relatório em produção
Se pronto para teste de sistemas ou usuário, copiar para a pasta SIN\Homologação, ainda com os indicadores de
data e versão
Criar um link do relatório para a pasta particular do usuário que irá testar e orientar sobre como acessar o relatório
Estando ok para produção:
Copiar o relatório original da pasta _BI Relatórios\Relatórios BI para a pasta SIN\Versões Antigas
acrescentando o prefixo <yyyymmdd>
Solicitar que o relatório homologado seja copiado, sobreescrevendo o relatório anterior e retirar o
prefixo <yyyymmdd>
Em qualquer situação, são necessárias as seguintes entradas de controle:

Novo Bug ou Change no TFS, associado ao requisito de relatório original


Pelo menos as atividades associadas ao Bug ou Change das disciplinas

Construction
Deployment
Test
Detalhamento de procedimentos
O documento Manual de Criação de Relatórios - BO31.doc possui outras informações sobre o procedimento, como criação
do relatório nas tabelas de controle, como associar os usuários ao relatório, etc.
Desenvolvimento de dashboard
Cabeçalho
A navegação entre abas deve ser feita com botões programados:
Apresentar o nome do usuário:
Os botões de ação devem ter o tamanho de 34 X 34 px:

Linha de filtros com botão de filtros, principais filtros em tela e Search box, todos com fonte Arial 11 normal.
Caixa de filtros
Encapsular a lista de opções de filtros em um container.
Fonte padrão: Arial 11px normal



Rodapé
Quando necessário, colocar um rodapé, usar fonte arial 8.
Padrão de cores
Usar a paleta padrão de cores do BIG, definindo variáveis para o uso correto.
O fundo do dashboard deve ser branco.
Usar como padrão de cores de fonte o cinza RGB (51,51,51)
Azul RGB(59,107,157)
Amarelo RGB(237,175,76)
Verde RGB(110,163,90)
Vermelho RGB(202,65,61)
Roxo RGB(131,81,139)
Cinza RGB(142,145,144)
Azul Claro RGB(85,174,215)
Laranja RGB(222,106,12)
Verde Escuro RGB(68,116,84)
Marrom RGB(132,71,71)
Roxo RGB(47,42,156)
Cinza Escuro RGB(93,93,94)
Divisão da tela
Caso seja necessário dividir a tela em setores, uma boa proporção é a seguinte, considerando uma tela de 980 X 735
(padrão da tela do iPad)



Seleções de hierarquia em gráficos
A alternativa default do QlikView de alternar a hierarquia de gráficos deve ser evitada.

A opção de botões programados como o abaixo deve ser escolhida:
Limitação de tela
 Opte pela resolução do iPad – 980px de largura
 Visualização Retrato X Paisagem
Dashboard que priorizam vários gráficos ficam melhor em Paisagem, mas para os que precisam mostrar tabelas
com vários registros, a opção Retrato é uma alternativa.
 Objeto Search
Como a tela é limitada, a quantidade de listboxes de filtro também é. O objeto search é uma ótima alternativa.


 Use a mesma cor para o mesmo item

Se vários gráficos usam a mesma dimensão, use a mesma cor para cada valor. Assim, uma única legenda vai servir
para vários gráficos.
 Gráficos X Tabelas
Procure usar a opção de alternância de visualização (fast change) para possibilitar a visualização de gráfico em
formato tabular
Visibilidade
 Use fonte Arial ou outra compatível com iPad.
Fontes como Tahoma são vistas como Times New Roman no iPad.
 Tamanho de fonte:
List Boxes: mínimo de 11px
Gráficos: mínimo de 9px
Tabelas: mínimo de 10 px
Títulos de Tabelas e gráficos: 12 px negrito
Indicadores: 12 px para o título do indicador, 28 px para o valor, 14 px para o complemento, se necessário
Totais: 14 px negrito para o valor do indicador, 12 px normal para o nome da métrica
 Alinhamento de texto
Cabeçalhos devem ser sempre alinhados à esquerda, exceto o de Indicadores que são centralizados.
 Atenuação de gráfico de linhas

Para melhorar a experiência, atenuar a linhas do gráfico, o que faz as linhas deixarem de ser retas para algo mais
senoidal
No BO: Formatar Gráficos -> Global -> Paleta e estilo – Marcar Opção: Linha de régua flexível.
Atenuada (smooth) Normal



Compatibilidade
Nem todas as fontes disponíveis no Qlik estão disponíveis quando acessadas em iPad.
Abaixo tem a lista de fontes compatíveis cross-platform, sendo que a prioridade e padrão é a Arial.
Usabilidade
 Seleções correntes
Coloque um objeto para exibir as seleções correntes. Pode ser chamando um ‘current selections box’, onde o usuário
poderá interagir com o objeto ou usar o “GetCurrentSelections()”.
 Botões de navegação
Os botões de Limpar seleção, Back, Forward são básicos e necessários.
 Evitar multi-boxes
Preferir a Search box
 Mouse over
Como não há mouse over em mobile, os gráficos devem deixar claro os valores que estão sendo exibidos
 Tamanhos de botões
Segundo o guia da Apple o tamanho mínimo para botões é de 44 X 44 pixels. Já a Microsoft sugere 34 pixels, com um mínimo
de 26 pixels.
Podemos considerar 44 pixels como ideal e 26 como mínimo.



Desenvolvimento em SAP Data Service
Objetos básicos utilizados no Desenvolvimento

Projects O objeto Project representa o nível mais alto de organização oferecido pelo Data Integrator.
Esse objeto é reutilizável e permite agrupar Jobs.
Datastores Canais lógicos que conectam o Data Integrator aos bancos de origem (source) e destino (target)
Jobs Objetos que são executados em modo batch ou real time.
Work Flows Definem a ordem de execução dos processos do Job de forma organizada
Data Flows Responsáveis pela extração, transformação e carga de dados.
Scripts Objetos não re-usáveis adicionados a Jobs e Work Flows.. Usados para definir valores à variáveis
e/ou executar funções.
Querys Recupera um conjunto de dados que satisfaz as condições especificadas.

Similar a declaração de SQL SELECT. Tem como entrada um conjunto de dados de uma ou mais
origens e como saída um único conjunto de dados podendo ter mais colunas e transformações
por funções.
Conditionals Estabelece a lógica de IF..THEN...ELSE no nível dos Work Flows
While Loops Permite que operações sejam repetidas enquanto uma expressão booleana não se torna
verdadeira
Tables Referências as estruturas das tabelas dos bancos relacionais. São componentes dos Datastores.
Template Tables Templates temporários que podem ser usados como tabelas destino (target) durante o
desenvolvimento.
File Formats Descrevem a estrutura de arquivos texto ou XML
Padrões de Nomenclatura
Para facilitar o entendimento dos processos, iremos adotar como padrão as seguintes definições, nome do objeto com
duas letras em minúsculo sendo a próxima palavra iniciada em maiúsculo e demais letras em minúsculo e assim
sucessivamente, conforme definições citadas abaixo:
Projects: pj<Ambiente><Desc>
Jobs: jb<JobPurpose>
Workflows: wf<WorkflowPurpose>
Dataflows: df<DataFlowPurpose>
Datasources: ds<Dbname>
File formats: ff<FileType><Name>


Custom Functions: fn<FunctionDesc>

Script: sc<SQLEntity>
Objetos de transformação
Query: qr<Entity><Number>
Table Comparison: tc<CompareTable>
History Preservation: hp<TargetTable>
Merge: mg<MergeEntity>
Map Operation: mo<MapOpPurpose>
Case: cs<CaseEntity>
Validation: vt<ValidationEntity>
Key_Generation: kg<KeyGenerationEntity>
Pivot: pv<PivotTable>
Reverse_Pivot: rp<Reverse_PivotEntity>
Row_Generation: rg<RowGenerationEntity>
SQL: sq<SQLEntity>
Variáveis
Global: gl<DataType><VarName>
Local: lo<DataType><VarName>
Parameter: pr<DataType><Direction><Name>
Functions: fc<Name>



 A SER INCREMETADA E DETALHADA
Atualização (refresh) das Views Materializadas

O jbDimAtualizaVwMaterializadas é chamado por outros jobs para realizar um “refresh complete” das viewa
materializadas que o BIG utiliza.
Com isso, foi feita a separação por grupos, que são os schedules das cargas cadastrados no Data Services.
O grupos estão cadastrados na TABELAAPOIO e seguem o quadro a seguir:
IDGRUPO DSGRUPO
510166 Carga - Outras
510167 Carga Atualiza última carga datas
510168 Carga Google Analytics
510169 Carga Incremental
510170 Carga Novas Mídias
510171 Carga Previsão Venda
510172 Carga Scheduall
510173 Carga Trust Diário
510174 Carga Tudo TV Diário
510175 Carga TV Mais Disponibilidade
510176 Carga Inserção Carteira
Cada id é passado em uma variável global do job que chama o JbDimAtualizaVwMaterializadas do seu respectivo grupo.
Com isso cada carga só vai dar refresh nas views que utilizam.
Abaixo, seguem os jobs alterados para contemplar essa alteração:
IDGRUPO JOB
510166 jbDimAtualizaOutrasMViews
510167 JbDimAtualizaCtUltimaCargaDatas
510168 jbRelAudienciaWeb
510169 jbDimFTInsercao
510170 jbDimFTInventarioWeb
510171 jbStgPrevisaoVenda
510172 jbDimFTOrdemServico
510173 jbDimFTReceitaProgramacao
510174 jbRelMergeTTVBig
510175 jbDimFTDisponibilidade
510176 jbDimFTInsercaoCarteira
Com isso, toda vez que for criado um job novo que tenha que chamar o JbDimAtualizaVwMaterializadas, deve ser seguido
o seguinte procedimento:



 Criar na TABELAAPOIO a linha com o nome da view materializada (se for nova), associando o IDGRUPOTABELAAPOIO e
o IDTIPOTABELAAPOIO à respectiva carga.
OBS: Se for uma carga nova, deve ser criada linha com o nome da nova carga;
 Sempre criar uma variável global no job que chama, com o valor inicial do grupo à qual pertence;
 Sempre utilizar o workflow wfDimAtualizaMV, pois o mesmo já possui a regra para a chamada do
jbDimAtualizaVwMaterializadas.
Carga na área de Stage

 Uma tabela/view de origem no legado deve ser uma tabela na área de Stage.
 Os nomes de tabelas da área de Stage receberam o prefixo STG e devem obedecer ao nome da tabela de origem. Os
campos seguirão a mesma nomenclatura da tabela de origem.
 Não deve haver transformações no processo de leitura do legado e carga na área de stage.
 A tabela a ser carregada deve ser truncada antes de cada processo de carga.
 Em geral Todas as extrações serão full. Exceto para a de Inserções.
 Extração full:
As tabelas que terão extração full sofrerão processo de balance-line para apurar se ocorreu uma inclusão, alteração ou
exclusão dos dados.
Em geral, será esta a opção para os processos de carga.

 Carga incremental
Optaremos por carga incremental das tabelas que possuam mais de 100mil registros.
Neste caso, usaremos o campo data mais confiável da tabela como critério de extração e serão extraídos os registros
com data maior ou igual ao primeiro dia do mês anterior à data de última extração menos 20 dias.
Por exemplo, considerando que a última extração da tabela de inserção foi no dia 10/02, extrairemos todas as
inserções com INS_Data >= 01/01.
Carga no Relacional
 Todas as tabelas do Relacional devem possuir os seguintes campos:
o Data de Inclusão: data em que o registro foi carregado pela primeira vez no Relacional. A referência é a
data do scheduler de carga.
o Data de Última Alteração: data da última alteração do registro. A referência é a data do scheduler de carga.
o Código Operacional do Sistema Origem: código usado pelo sistema legado.
o Indicador de Exclusão na Origem: indica se o registro foi excluído no sistema Origem. Domínio: 0 (Não) / 1
(Sim). Default 0 (Não).
 Não está prevista a exclusão de registros no Relacional. Os registros que não existirem na área de stage devem ter o
indicador de exclusão alterado para Sim (inExclusaoOrigem=1).
 Todas as tabelas do Relacional devem ter sua chave numérica sequencial criada no Relacional (surrogate key) com
base no código operacional do sistema de origem. No caso de tabelas de relacionamento, a alternate key deve ser
definida. O SAP Data Service deve considerar a alternate key para criar novos registros ou alterar os já existentes.
 As foreign keys devem ser traduzidas para os valores das chaves do Relacional.


 O processo de inicialização do Relacional (one-time) deve carregar os Valores Default de Chaves em todas as tabelas
antes do início da carga inicial.
 O processo de balance-line para a carga do relacional de tabelas de extração incremental deve considerar que a tabela
stage terá somente parte dos dados totais e somente os registros com data posterior à data do critério é que poderão ser
considerados como exclusão.
 As lookups que usam dados carregados na TabelaApoio devem usar a view criada para o tipo de tabela criado. Abaixo
temos um exemplo:
lookup_ext(
[dsBigRel.BIGPRDREL.vwSituacaoInsercao, 'PRE_LOAD_CACHE', 'MAX'],
[ IDSITUACAOINSERCAO ],
[ -2 ],
[ CDOPERSISTORIG, '=', STGVWINSERCOESBI.ID_SITUACAO ],
[ IDSITUACAOINSERCAO ])
SET("run_as_separate_process" = 'no')
 Carga de dados de Disponibilidade: Apesar dos dados de Disponibilidade não se enquadrarem no critério de 100mil
registros, o processo de carga será do tipo incremental pois o TV+ não retém os dados de dias anteriores ao corrente. Por
isso, a carga no relacional deve considerar somente os dados da stage com data posterior à data corrente.
Valores Default de Chaves

Id Descrição Observação
-1 Não Identificado Usado quando o processo de carga não consegue encontrar a
chave do Relacional correspondente para uma chave vinda do
transacional
-2 Não Definido Nulo na Origem
-3 Múltiplos Valores Quando a informação de um registro “pai” é gerada pela análise
dos valores dos registros “filhos” e que não possuem um único
valor. Por exemplo o Setor Econômico de uma Holding sendo
gerado pelo Setor Econômico das diversas empresas subordinadas.
-4 Não Aplicável O atributo não se aplica para o registro. Por exemplo segmento de
mercado para contatos.
-5 Previsão Quando o registro é gerado por processos preditivos.
Carga no Dimensional
 Os processos de carga de fatos com origem no Relacional devem considerar o indicador de exclusão na Origem para
excluir os registros excluídos na origem. Por exemplo a fato de inserções não pode carregar os registros excluídos no TV+.
 As fatos serão particionadas por mês de referência da carga. A cada nova carga, a partição que será carregada deve ser
truncada e depois carregada.
 As doze partições de um ano deverão ser criadas em Dezembro do ano anterior. Isso deverá ser solicitado aos DBAs de
Sistemas.
 As dimensões deverão ser views materializadas das tabelas ou views do Relacional.



 Visando uma maior disponibilidade dos dados para os usuários, o processo de carga das fatos deve seguir os seguintes
passos:
1. Truncar a tabela de trabalho da tabela Fato.
2. Carregar a tabela de trabalho com os dados atualizados para a data de referência.
3. Trucar a partição da tabela fato para a data de referência a ser carregada.
4. Carregar a tabela fato com os dados da tabela de trabalho.
Esse procedimento evita que a tabela fato fique indisponível caso o processo de carga abend durante a carga
da tabela de trabalho.
Camada Semântica
 O Universo BO é a solução de camada semântica adotada pela Globosat
 As dimensões que podem ser reutilizadas deverão ficar no Universo Corporativo
 O Universo Corporativo deverá ser ligado ao universo da fato
 Os universos deverão ser construídos em formato estrela (star schema) apontando para tabelas fato ou views
materializadas do esquema Dimensional
 As regras e segurança de acesso aos dados deverão ser implementados universo da fato, nunca no Universo
Corporativo
Política de atualização e retenção

 Os dados serão atualizados diariamente de Domingo à Segunda-feira.
 A janela preferencial de atualização é de 22:00 às 07:00hs para atualização diária. Durante o processo de carga os
dados devem ficar indisponíveis para os usuários.
 A granularidade das fatos será mensal. Como a carga será diária, a cada carga os dados do mês corrente serão limpos
e as informações atualizadas serão inseridas.
 As fatos terão retenção de ao menos 5 anos.



Convenções, Termos e Abreviações

Para evitar interpretações incorretas deste documento, algumas convenções e termos específicos são descritos a seguir:


Padrões de Desenvolvimento SIN

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

Padrões de Desenvolvimento SIN

Enviado por

Direitos autorais:

Formatos disponíveis

SI - Informações de Negócios

Padrões de desenvolvimento SIN

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Histórico de Alterações no Documento

Versão Data Atividade Responsável

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Divisão da tela ............................................................................................................. 16

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Padrão para Modelagem de Dados

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Exemplo de chaves sem referência:

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Bordas, fundos e contornos

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

As tabelas abaixo devem seguir o seguinte alinhamento:

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Controle de versão de relatórios

Relatório novo sem mudança de universo

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Testar o relatório em produção

Alteração de relatório com mudança de universo

Alteração de relatório sem mudança de universo

Em qualquer situação, são necessárias as seguintes entradas de controle:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Pelo menos as atividades associadas ao Bug ou Change das disciplinas

A navegação entre abas deve ser feita com botões programados:

Apresentar o nome do usuário:

Os botões de ação devem ter o tamanho de 34 X 34 px:

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica

Elaborado por: Revisado por: Homologado por: Impresso em:

*Informação classificada como pública e de circulação irrestrita.

Padrões de desenvolvimento SIN - Documentação técnica