Formulário_PFBD_v3.odt

Levantamento para Elaboração de

Projeto Físico de Banco de Dados

Versão 3.0

DEPI / DPBP

Elaboração

Verificação

João Fernando R. De Siqueira

Gestor da Demanda

<Nome do analista DBA Projetista

responsável pela verificação>

Divisão de Projeto de Banco de Dados e

Produtos - DPBP

Data: ____/____/________

Data: ____/____/________

Histórico de Revisões

Nº Data Descrição

1

08/10/2012 Versão Inicial

Índice Analítico

1. Objetivo

...

4

2. Informações sobre o projeto

...

4

3. Conectividade ao Banco de Dados

...

5

4. Interfaces

...

5

5. Estruturas de Banco de Dados

...

6

6. Aplicação

...

8

7. Procedimentos externos

...

10

1. Objetivo

Este levantamento tem como objetivo obter informações que subsidiarão o projeto

físico de bases de dados de homologação e produção bem como para auxiliar na

tomada de decisão do SGBD (sistema de gerenciamento de banco de dados) a ser

escolhido para implementação do projeto.

Este deverá ser preenchido previamente pela equipe de desenvolvimento do sistema,

antes da criação da base de dados e quando houver um conjunto de alterações

significativas na base de dados, devido à evolução do modelo de dados. A melhor

escolha do SGBD, o correto dimensionamento e qualidade do projeto de banco de

dados e seu suporte, dependerá diretamente da exatidão e do detalhamento das

respostas das questões deste questionário.

2. Informações sobre o projeto

Iteração: 1

Produtos da iteração: Nome do Gestor:

Tipo de Aplicação: ( OnLine, Batch, Tempo Real)

Telefone de Contato: E-mail:

Previsão das próximas iterações:

3. Conectividade ao Banco de Dados

Utiliza pool de conexões? (X )Sim ( ) Não

Quantidade de conexões simultâneas abertas:

Será implementado método de autenticação seguro SSL? (X )Sim ( ) Não

4. Interfaces

Plataforma baixa:

[Como será implementada as integrações com sistemas da plataforma baixa]

Sistema Método de acesso Objeto Nome do Serviço

[apl, classe java ou dblink] [nome da classe ou dblink] [descrição do acesso ao serviço]

Plataforma alta (CV2, CV3 e MV2):

Não se aplica.

Sistema Método de acesso Objeto Nome do Serviço

[nome do sistema] [apl, classe java ou dblink] [nome da classe ou dblink] [descrição do acesso ao serviço]

5. Estruturas de Banco de Dados

Tabelas candidatas a particionamento:

[Tabelas que possuem grande volume de dados e são muito acessadas]

Owner Tabela Método de

Particionamento Critério de Particioname nto Volume Total Crescimento Mensal E-mail do Responsável

SIDI LOGS_EVENTOS Range DT_LOG_E

VENTO 100.000.000 7.300.000 Joao.rdesiqueira@dataprev.gov.br SIDI LOG_USUARIOS Hash ID 100.000.000 7.300.000 Joao.rdesiqueira@datapr

ev.gov.br SIDI CONTAGENS_AC

ESSOS

Hash ID 50.000.000 3.500.000 Joao.rdesiqueira@datapr ev.gov.br

Tabelas candidatas a compactação:

Owner Tabela Volume Total E-mail do Responsável

Check constraints /Fks deverão ser habilitadas para dados legados? Descreva.

Índices para carga:

Tabelas que utilizarão algum tipo de dados especial:

Nome da Tabela Atributo Tipo de dado E-mail do reponsável SOLICITACOES_AUDITORIAS_ANEXOS IMAGEM_DOCUMENTO BLOB Joao.rdesiqueira@dataprev.

gov.br

SOLICITACOES_AUDITORIAS_ANEXOS TEXTO_DOCUMENTO BLOB Joao.rdesiqueira@dataprev. gov.br

6. Aplicação

Característica da aplicação: (x ) OLTP ( )OLAP

Haverá procedimentos e funções escritas no SGBD? Descreva.

Transações críticas:

Muito executadas e com tempo de resposta crítico:

Nome da Tabela Transação Descrição E-mail responsável

LOGS_EVENTOS INSERT, SELECT A tabela recebe inclusões em grande volume, porém é consultada ocasionalmente.

Joao.rdesiqueira@dataprev.gov.br

LOG_USUARIOS INSERT, SELECT A tabela recebe inclusões em grande volume, porém é consultada ocasionalmente.

Joao.rdesiqueira@dataprev.gov.br

Com acesso a tabelas muito grandes e com tempo de resposta crítico:

Nome da Tabela Transação Descrição E-mail responsável

LOGS_EVENTOS INSERT, SELECT A tabela recebe inclusões em grande volume, porém é consultada ocasionalmente.

Joao.rdesiqueira@dataprev.gov.br

LOG_USUARIOS INSERT, SELECT A tabela recebe inclusões em grande volume, porém é consultada ocasionalmente.

Joao.rdesiqueira@dataprev.gov.br

CONTAGENS_ACESSOS SELECT A tabela é consultada ocasionalmente, uma vez por mês.

Joao.rdesiqueira@dataprev.gov.br

Complexas (vários joins) e com tempo de resposta crítico:

Principais filtragens:

Nome da Tabela Atributos Descrição E-mail responsável

LOGS_EVENTOS DT_LOG_EVENTO Consulta por Periodo

Joao.rdesiqueira@dataprev.gov.br

LOG_USUARIOS CS_TIPO_USUARIO Filtro por Tipo

de Usuario Joao.rdesiqueira@dataprev.gov.br LOG_USUARIOS CS_TIPO_ABRANGENCIA Filtro por Tipo

de Abragencia Joao.rdesiqueira@dataprev.gov.br

Ordenações a grupamentos:

Nome da Tabela Atributos Asc/Desc E-mail responsável

CONTAGENS_ACESSOS nu_abrangencia, sg_sistema_origem, sg_subsistema_origem, cs_usuario ASC Joao.rdesiqueira@dataprev.gov.br LOGS_EVENTOS sg_sistema_origem e

sg_subsistema_origem ASC Joao.rdesiqueira@dataprev.gov.br LOGS_EVENTOS nm_funcionalidade ASC Joao.rdesiqueira@dataprev.gov.br LOGS_EVENTOS dt_log_evento ASC Joao.rdesiqueira@dataprev.gov.br

Utilização de variáveis bind:

( ) Sempre (em todas as consultas)

(

x

) Usa em parte (relacionar consultas abaixo)

( ) Não usa bind

Previsão de avaliação de desempenho de queries? .

SELECT 'INSS' AS EMPRESA, S.SG_SISTEMA_ORIGEM, SS.SG_SUBSISTEMA_ORIGEM, CA.CS_USUARIO, SUM(CA.QT_ACESSOS)

FROM CONTAGENS_ACESSOS CA, SUB_SISTEMAS_ORIGEM SS, SISTEMAS_ORIGEM S WHERE CA.ID_SUBSISTEMA_ORIGEM = SS.ID_SUBSISTEMA_ORIGEM

AND SS.ID_SISTEMA_ORIGEM = S.ID_SISTEMA_ORIGEM AND CA.ID_SOLIC_CONTAGEM_ACESSO = ?

AND CA.CS_ABRANGENCIA = 1

GROUP BY 'INSS', S.SG_SISTEMA_ORIGEM, SS.SG_SUBSISTEMA_ORIGEM, CA.CS_USUARIO UNION ALL

SELECT TO_CHAR(CA.nu_abrangencia) AS EMPRESA, S.SG_SISTEMA_ORIGEM, SS.SG_SUBSISTEMA_ORIGEM, CA.CS_USUARIO, SUM(CA.QT_ACESSOS)

FROM CONTAGENS_ACESSOS CA, SUB_SISTEMAS_ORIGEM SS, SISTEMAS_ORIGEM S WHERE CA.ID_SUBSISTEMA_ORIGEM = SS.ID_SUBSISTEMA_ORIGEM

AND SS.ID_SISTEMA_ORIGEM = S.ID_SISTEMA_ORIGEM AND CA.ID_SOLIC_CONTAGEM_ACESSO = ?

AND CA.CS_ABRANGENCIA = 2

CA.CS_USUARIO

/* CONSULTA TOTAL DE LOG DE EVENTOS POR SISTEMA E SUBSISTEMA */ SELECT S.NM_SISTEMA_ORIGEM, SS.NM_SUBSISTEMA_ORIGEM,

SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '01', 1, 0)) AS JANEIRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '02', 1, 0)) AS FEVEREIRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '03', 1, 0)) AS MARCO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '04', 1, 0)) AS ABRIL, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '05', 1, 0)) AS MAIO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '06', 1, 0)) AS JUNHO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '07', 1, 0)) AS JULHO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '08', 1, 0)) AS AGOSTO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '09', 1, 0)) AS SETEMBRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '10', 1, 0)) AS OUTUBRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '11', 1, 0)) AS NOVEMBRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '12', 1, 0)) AS DEZEMBRO FROM LOGS_EVENTOS L, LOG_USUARIOS U, ACOES A, FUNCIONALIDADES F, SUB_SISTEMAS_ORIGEM SS, SISTEMAS_ORIGEM S

WHERE L.ID_LOG_USUARIO = U.ID_LOG_USUARIO AND L.ID_ACAO = A.ID_ACAO

AND A.ID_FUNCIONALIDADE = F.ID_FUNCIONALIDADE AND F.ID_SUBSISTEMA_ORIGEM = SS.ID_SUBSISTEMA_ORIGEM AND SS.ID_SISTEMA_ORIGEM = S.ID_SISTEMA_ORIGEM

AND SS.ID_SISTEMA_ORIGEM = ? AND SS.ID_SUBSISTEMA_ORIGEM = ?

GROUP BY S.NM_SISTEMA_ORIGEM, SS.NM_SUBSISTEMA_ORIGEM /* CONSULTA TOTAL DE LOG DE EVENTOS POR FUNCIONALIDADE */ SELECT F.NM_FUNCIONALIDADE, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '01', 1, 0)) AS JANEIRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '02', 1, 0)) AS FEVEREIRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '03', 1, 0)) AS MARCO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '04', 1, 0)) AS ABRIL, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '05', 1, 0)) AS MAIO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '06', 1, 0)) AS JUNHO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '07', 1, 0)) AS JULHO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '08', 1, 0)) AS AGOSTO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '09', 1, 0)) AS SETEMBRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '10', 1, 0)) AS OUTUBRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '11', 1, 0)) AS NOVEMBRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '12', 1, 0)) AS DEZEMBRO FROM LOGS_EVENTOS L, LOG_USUARIOS U, ACOES A, FUNCIONALIDADES F, SUB_SISTEMAS_ORIGEM SS, SISTEMAS_ORIGEM S

WHERE L.ID_LOG_USUARIO = U.ID_LOG_USUARIO AND L.ID_ACAO = A.ID_ACAO

/* CONSULTA TOTAL DE LOG DE EVENTO POR ANO */ SELECT TO_CHAR(L.DT_LOG_EVENTO, 'YYYY') AS ANO,

SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '01', 1, 0)) AS JANEIRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '02', 1, 0)) AS FEVEREIRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '03', 1, 0)) AS MARCO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '04', 1, 0)) AS ABRIL, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '05', 1, 0)) AS MAIO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '06', 1, 0)) AS JUNHO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '07', 1, 0)) AS JULHO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '08', 1, 0)) AS AGOSTO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '09', 1, 0)) AS SETEMBRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '10', 1, 0)) AS OUTUBRO, SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '11', 1, 0)) AS NOVEMBRO,

SUM(DECODE(TO_CHAR(L.DT_LOG_EVENTO, 'MM'), '12', 1, 0)) AS DEZEMBRO FROM LOGS_EVENTOS L, LOG_USUARIOS U, ACOES A, FUNCIONALIDADES F,

SUB_SISTEMAS_ORIGEM SS, SISTEMAS_ORIGEM S WHERE L.ID_LOG_USUARIO = U.ID_LOG_USUARIO AND L.ID_ACAO = A.ID_ACAO

AND A.ID_FUNCIONALIDADE = F.ID_FUNCIONALIDADE

AND F.ID_SUBSISTEMA_ORIGEM = SS.ID_SUBSISTEMA_ORIGEM AND SS.ID_SISTEMA_ORIGEM = S.ID_SISTEMA_ORIGEM AND SS.ID_SISTEMA_ORIGEM = ?

AND SS.ID_SUBSISTEMA_ORIGEM = ?

GROUP BY TO_CHAR(L.DT_LOG_EVENTO, 'YYYY') /* CONSULTA TOTAL DE LOG DE EVENTO POR PERIODO */ SELECT count(le.id_log_evento)

from logs_eventos le, sub_sistemas_origem sso, sistemas_origem so, funcionalidades f, acoes a where le.id_acao = a.id_acao

and a.id_funcionalidade = f.id_funcionalidade

and f.id_subsistema_origem = sso.id_subsistema_origem and sso.id_sistema_origem = so.id_sistema_origem and sso.id_subsistema_origem = " + ?

and so.id_sistema_origem = "+ ?

and le.dt_log_evento between TO_DATE('"+ ? +"', 'dd/MM/yyyy') AND TO_DATE('"+ ? +"','dd/MM/yyyy')") group by sso.id_subsistema_origem, so.id_sistema_origem"

7. Procedimentos externos

Não se aplica.

Listagem dos procedimentos:

Nome da Procedimento Descrição da Funcionalidade Linguagem

Existência de transação de banco de dados envolvendo envio de e-mail? Descreva.

O processo de contagem de total de acesso envia um e-mail ao usuario que

solicitou a contagem de total de acesso.

Existência de transação de banco de dados envolvendo Upload / Download de

arquivos?

A solicitacao de auditoria deve permitir anexar imagens e documentos ( .pdf,

.odt, .doc )

8) Procedimento de Carga / Batch / Emissão de relatórios

8.1) Execução de cargas / processos Batch / emissão de relatórios?

Haverá um processo batch para geração do relatório de total de acesso

Haverá um processo batch para contingencia do serviço de log de

evento

8.2) Como serão realizados: Java Batch / SqlLoader / Pl/SQL, etc?

8.4)

Existência de log de execução?

Sim será gerado para os processos batch de contingencia do serviço de log de

evento e contagem de total de acessos através de componente Log4J.

8.5) Reinício do processo a partir do ponto em que parou em caso de falha

(restart)?

Sim. Os processos são reiniciados a partir do ponto em que pararam. Há um

controle de reinicialização que foi implementado via SpringBatch.

8.6) Durante o processo de carga / batch, haverá alguma interface com outra

base de dados?

Não haverá interface com outra base de dados.

9)Administração

9.1) Qual a disponibilidade da aplicação?

Mesma disponibilidade do sistema PortalCNIS.

9.2) Podem existir janelas de manutenção? Qual o tempo aceitável?

Sim. Preferencialmente fora do horário de expediente para não causar

impacto no PortalCNIS.

9.3) Qual o tempo médio de resposta da aplicação, considerado pelo cliente final?

Até 1 segundo para cada registro de log de evento

Até 5 segundos para as consultas de log de eventos

10)Backup

10.1) Definição da rotina de backup: Offline e On-line em função da janela de

indisponibilidade do sistema.

Rotina de Backup Off-Line para não afetar o desempenho do banco de

dados.

10.2) Definição do prazo de retenção de backup.

Devem ser guardados por tempo indeterminado por se destinam a gerar

auditoria

11) Log de transações

11.1) Forma de implementação:

Será implementado via componente do Log4J.

11.2) Existência de expurgo?

A cada 10 anos deve haver expurgo dos dados de log de eventos.

12) Controle de acesso

12.1) SAA?

Não será utilizado o SAA.

12.2) Outros?

Usuário para o módulo on-line - Gestor do SIDI ( Módulo de Cadastros )

Usuário para o serviço de Log de Evento ( EJB SIDILog )

Usuário para os processos batch ( Contingencia de Log de Evento e

Contagem de Total de Acessos )

13.2) Quais privilégios deverão ser concedidos a esses usuários?

Consulta e atualização de dados em todas as tabelas.

14) Expurgo

14.1) Quais são as tabelas envolvidas?

LOGS_EVENTOS,

LOG_USUARIOS,

SOLICITACOES_CONTAGENS_ACESSOS e CONTAGENS ACESSOS,

SOLICITACOES_AUDITORIAS e AUDITORIAS

14.2) Como é o processo e a periodicidade?

Periodicidade a cada 10 anos.