PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL IICA/BRA/13/003 –

NOVA RURALIDADE BRASILEIRA: COMPREENSÕES E IMPLICAÇÕES NA

POLÍTICA PÚBLICA

Produto 2 – Documento técnico contendo levantamento e

mapeamento de dados da DAP e do Garantia Safra, com
respectivos modelos de banco de dados (modelo
dimensional) para armazenamento dos dados, modelo do
processo ETL para extração dos dados levantados e carga
no modelo proposto.

Gilmar Correa dos Santos

Consultor

Brasília/DF
Junho/2018
 INSTITUTO INTERAMERICANO DE COOPERAÇÃO PARA A AGRICULTURA
FOLHA DE ROSTO PARA PRODUTOS DE COOPERAÇÃO TÉCNICA

Identificação
Consultor (a) / Autor (a): Gilmar Correa dos Santos
Número do Contrato: 118103
Nome do Projeto: PCT/ IICA/BRA/13/003 – Nova Ruralidade Brasileira: Compreensões e
Implicações na Política Pública
Oficial/Coordenador Técnico Responsável – IICA: Cristina Costa
Data Local: 10 de junho de 2018/Brasília - DF
Classificação
Temas Prioritários
Agroenergia e Biocombustíveis Sanidade Agropecuária
Biotecnologia e Biossegurança Tecnologia e Inovação X
Comércio e Agronegócio X Agroindústria Rural
Desenvolvimento Rural X Recursos Naturais
Políticas e Comércio X Comunicação e Gestão do Conhecimento
Agricultura Orgânica Outros:
Modernização Institucional X

Palavras-Chave:
Inteligencia de Negócio; DW; BI; BA; Business Intelligence; Business Analytics; Software Livre;
FOSS; Dados; Informação; Gestão
Resumo
Título do Produto: Produto 2
Subtítulo do Produto: Documento técnico contendo levantamento e mapeamento de dados dos
contextos DAP e do Garantia Safra, com respectivos modelos de banco de dados (modelo
dimensional) para armazenamento dos dados, modelo do processo ETL para extração dos dados
levantados e carga no modelo proposto.
Resumo do Produto:
Construção de modelo de dados dimensional em tecnologia EBD PostgreSQL que armazena
dados oriúndos de dados originários de fontes em SGBD SQL SERVER referente aos contextos
DAP e Garantia Safra e que se refiram aos indicadores chave de desempenho (KPI’s)
identificados durante a análise inicial agrupados e provenientes do DAP: 1) Número de DAP’s
Principais; 2) Número de DAP’s Jurídicas; 3) Número de DAP’s Jovens; 4) Número de DAP’s
Mulher e provenientes do Garantia Safra: 5) Quantidade de Agricultores aderidos ao Garantia
Safra; 6) Quantidade de Agricultores beneficiados pelo Garantia Safra; 7) Quantidade de Valor do
Garantia Safra; 8) Número de Municípios aderidos ao Garantia Safra. Esses indicadores
permitiram configurar as regras fundamentais para construção do modelo de Data Warehousing.
Qual Objetivo Primário do Produto?
Apresentar ao NEAD possíveis soluções de modelo dimensional que atenda aos indicadores
chaves de desempenho (KPI’s) que envolvam os dados referentes aos contextos DAP e Garantia
Safra. Bem como, solução de visualização de dados baseadas em soluções FOSS – Free and
Open Source Software – Software livre e de Código Aberto.
Que Problemas o Produto deve Resolver?
Identificar os indicadores chaves provenientes dos sistemas DAP e Garantia Safra e que são de
interesse do NEAD que permitam desenhar solução de Data Warehousing e organizar
ferramentas que promovam a visualização espacial dos dados que compõem esses indicadores.
Como se Logrou Resolver os Problemas e Atingir os Objetivos?
Promoveu-se a identificação dos indicadores a partir das análise das necessidades do negócio e
requisitos funcionais e não funcionais. Em seguida, aplicou-se arquitetura de dados para a
construção de modelos dimensionais que atendessem as necessidades e requisitos identificados.
A partir da construção do modelo, promoveu-se a carga de amostra de dados para testes
funcionais e de desempenho das soluções apresentadas.
Quais Resultados mais Relevantes?
A integração harmônica e consistente de ferramentas integradas que permitam a apresentação
espacial dos dados referentes aos indicadores chaves de desempenho (KPI’s) identificados no
processo de análise de necessidade e requisitos. Todas as ferramentas foram desenvolvidas
segundo a filosofia FOSS (Software Livre e de Código Aberto) e de forma que a operação da
solução envolvessem o menor número de operadores possível, em virtude, das restrições de
pessoal existente no NEAD.
O Que se Deve Fazer com o Produto para Potencializar o seu Uso?
O produto é apresentado em formato conceitual e implantado em servidor temporário. Caso o
NEAD faça a opção por adotar a solução em definitivo é necessário a disponibilização de, pelo
menos, dois servidores (hardware) disponibilizados com sistemas operacional linux ou windows
que possam abrigar as ferramentas que compõem a solução de forma definitiva. A configuração
miníma desses hardware são: Memória RAM 16 Gb; Espaço de Hard Disk: 1 Tb.
 Table of Contents
APRESENTAÇÃO..................................................................................................................... 5
FERRAMENTAS........................................................................................................................6
PROCESSOS.............................................................................................................................. 7
DEFINIÇÃO DOS PADRÕES DE NOMENCLATURA DE OBJETOS...................................7
PADRÃO DE NOMENCLATURA DE OBJETOS DE DADOS...............................................7
PADRÃO DE NOMENCLATURA DE ROTINAS DE CARGA NO TALEND OPEN
STUDIO DATA INTEGRATOR (TOS-DI)..............................................................................10
IDENTIFICAÇÃO DE NECESSIDADES...............................................................................10
IDENTIFICAR OS INDICADORES CHAVE DE DESEMPENHO (KPI) RELACIONADOS
Aos contextos............................................................................................................................ 11
CONCEPÇÃO DE MODELO DIMENSIONAL PARA ABRIGAR OS DADOS DOS
INDICADORES CHAVE DE DESEMPENHO IDENTIFICADOS........................................15
DATAMART’S DEFINIDOS PARA O ARMAZÉM DE DADOS..........................................17
IMAGEM DO MODELO DE DADOS CONCEITUAL DO ARMAZÉM DE DADOS
PROPOSTO PARA ESTOCAGEM DOS DADOS REFERENTES AOS INDICADORES
CHAVES DO DAP E GARANTIA SAFRA.............................................................................18
DESCRIÇÃO DO MODELO DIMENSIONAL PROPOSTO PARA O ARMAZÉM DE
DADOS (DW)...........................................................................................................................19
CONSTRUÇÃO DA SOLUÇÃO.............................................................................................24
SCRIPT GERADO PELA FERRAMENTA SQL POWER ARCHTECT PARA CRIAÇÃO
DAS ENTIDADES DE DADOS DOS DDM’S QUE COMPÕEM O DW.............................24
CONSTRUÇÃO Das rotinas DE CARGA NA FERRAMENTA TALEND OPEN STUDIO
DATA INTEGRATOR (TOS-DI)..............................................................................................33
CONCEPÇÃO DA CAMADA DE VISUALIZAÇÃO COM A UTILIZAÇÃO DAS
FERRAMENTAS SPAGOBI E DJANGO............................................................................... 52
CONCLUSÃO.......................................................................................................................... 55
BIBLIOGRAFIA...................................................................................................................... 56
 APRESENTAÇÃO

Este documento técnico contém a definição dos indicadores chave de

desempenho (KPI’s) e que serviram de guia inicial para a identificação das
necessidades fundamentais para a construção do modelo relacionados aos
contextos: Documento de Aptidão ao PRONAF – DAP e Garantia Safra – GS.
Bem como, o levantamento e o mapeamento de dados referentes aos referidos
contextos. A partir da identificação das necessidades fundamentais, partiu-se
para a concepção dos respectivos modelos dimensionais para a acomodação
dos dados e, a consequente, montagem das rotinas para extração,
transformação e cargas (ETL) dos dados necessários aos cumprimentos dos
requisitos identificados. Além disso, este documento técnico apresenta
sugestões de regras e padrões de taxonomia e ontologia para nomenclatura
dos dados cadastrados no Data Warehouse (DW) [Kimball, R. & Ross, M.,
2013] e painéis contendo resultados de análises construídos a partir do modelo
proposto na Ferramenta SpagoBI para demonstrar as possibilidades e
capacidades de uso, harmonia e integração operacional das ferramentas que
compõem a solução e que são todas construídas sob filosofia FOSS
[SÖDERBERG, J, 2008] - Free Open Source Software (Software Livre e de
Código Aberto). Atendendo aos requisitos sugeridos pela Coordenação-Geral
de Gestão Estratégica, Monitoramento e Avaliação – NEAD da Secretaria
Especial da Agricultura Familiar e do Desenvolvimento Agrário – SEAD,
conforme consta no Termo de Referência (TR) [NEAD, 2017] do contrato
118103 do projeto PCT/ IICA/BRA/13/003 para o produto 2.
 FERRAMENTAS
Todas as ferramentas utilizadas para a construção dos artefatos
apresentados neste produto são baseadas em filosofia FOSS [SÖDERBERG,
J, 2008] – Free Open Source Software, que se refere a ferramentas de
software construídas sob licenças de código aberto [PUC-Rio, 2018] e de uso
livre que é um requisito não funcional explicito do projeto. Desta feita, utilizou-
se as seguintes ferramentas:

id Nome da Ferramenta Versão Utilidade

1 Power Architect 1.0.8 Ferramenta de Modelagem de Dados Dimensional
2 GeoServer 2.10.2 Repositório de Mapas Geográficos
3 QGIS 3.0 Tratamento de Arquivos contendo Informações
Geográficas.
4 PostgreSQL 9.3 Sistema Gerenciador de Banco de Dados (SGBD).
5 Inkscape 0.92 Ferramenta de livre para editoração eletrônica de
arquivos vetoriais.
6 SpagoBI Server, Studio e 5.2 Conjunto de Ferramentas de Business Intelligence – BI.
Meta.
7 Talend Open Studio – 6.5.1 Ferramenta para Integração de Dados (ETL).
Data Integration (TOS-DI)

Tabela 1: Lista de Ferramentas utilizadas no projeto.

Algumas dessas ferramentas, devidamente instaladas e configuradas

permitem a operação conjunta e harmoniosa alcançando a automação de
processos e dispensando a interferência massiva de mão-de-obra
especializada. Outras, servem como subsídio para a adequação e
tratamento e/ou padronização de arquivos. Esse conjunto operacional foi
concebido pensando na precária disponibilidade de profissionais para
operação de pocessos, em virtude das características do corpo funcional
que compõe o NEAD.
 PROCESSOS
Para a construção eficiente de produtos de software é prudente a
adoção de um conjunto claro e integrado de processos [SOMMERVILE, I.
2011] interligados, que permitam o controle, acompanhamento e
documentação do trabalho de forma eficiente. Para este produto foram
adotados os seguintes processos formais:

id Nome do Processo Observação

1 Definição dos Padrões de Nomenclatura de Objetos
2 Identificação de Necessidades
3 Identificação de Fontes de Dados
4 Construção de Modelo Dimensional dos Data Marts
(DDM).
5 Construção das Rotinas de Integração de Dados (ETL)
6 Construção de Análises e Painéis com os dados
carregados nos processos anteriores.
Tabela 2: Tabela de Processos necessários para construção da solução.

Essa subdivisão em processos permite a compreensão didática das

tarefas definidas e executadas para a construção dos produtos com as
definições claras de cada etapa do projeto.

1. DEFINIÇÃO DOS PADRÕES DE NOMENCLATURA DE

OBJETOS
A definição de padrões de nomenclatura de objetos é um primeiro
passo para a definição de um protocolo para construção de sistemas de
Business Intelligence (Inteligência Negocial) – BI e outros sistemas em geral.
Afinado com essa premissa, definiu-se as seguintes regras:

1.1. PADRÃO DE NOMENCLATURA DE OBJETOS DE DADOS

Para a nomenclatura dos objetos de dados dimensional sugeriu-se os
seguintes padrões:
 a) A nomenclatura sugerida para a denominação de Banco de Dados
segue o padrão nnnn_bd. Onde:

nnnn → Acrônimo ou termo relacionado ao Banco de Dados;

bd → Sufixo que identifica o objeto como um Banco de Dados.

Exemplo: nead_bd

b) A nomenclatura de Entidade de Dados Dimensional – Existem dois

tipos de objetos de Dados Dimensionais:

b.i) os objetos denominados Dimensões – DM (que armazenam

as questões possíveis dentro de um Data Mart - DDM) e

b.ii) os objetos denominados Fatos – FT (que armazenam as

respostas possíveis às questões propostas).

Para a nomenclatura desses tipos de entidades de dados adotou-se o

seguinte padrão de nomenclatura: dm_nnn_nnnnnn ou ft_nnn_nnnnnn.
Onde:

dm ou ft → Prefixo que identifica se o objeto é uma dimensão ou uma

fato;

nnn_nnnnn → Quando a nomenclatura do objeto for composta. Por

exemplo, tiver mais do que uma palavra para identificar o assunto, como
exemplo: pessoa juridica. Deve-se utilizar os tres caracteres da primeira
palavra, por exemplo, pes e a segunda palavra na íntegra, ou de outra forma,
utilizar todos os termos na íntegra, pelo bem da clareza e contra qualquer
redundância. Desta feita, a nomenclatura sugerida seria: dm_pes_fisica ou,
com mais clareza, dm_pessoa_fisica. Pois se trata de uma entidade de dados
do tipo dimensão que armazena atributos ou colunas relativas ao assunto
pessoa física. Caso, apenas uma palavra identifique a coleção de dados,
deve-se utilizar a palavra em sua integralidade, como o exemplo a seguir:
dm_categoria.

c) Nomenclatura de Colunas de Dados – para a nomenclatura de

colunas de dados, deve-se seguir o seguinte padrão: pp_nnn_mmmmm.
Onde:
 pp → prefixo que identifica a função da coluna que está relacionada a
tipologia do dado armazenado pelo objeto dentro da coleção de dados,
segundo a seguinte tabela:

sigla Significado Tipos Função

an ano Integer; Int; Armazena dados numéricos
Char; referentes ao ano.
Numérico.
dt data Date Armazena dados do tipo
data.
ds descrição Text; Character Armazena dados textuais
Varying; String; que armazena descrições
Text Long etc.
dr duração Integer; Int; Armazena dados numéricos
Char; relativos a um intervalo de
Numérico. uma unidade definida: dia,
mês ou ano.
id Identificador Integer; Int; Armazena dados com a
Char; função de Chave Primária
Numérico. ou Chave Estrangeira na
entidade de dados.
in Indicador Integer; Int; Armazena dados relativos
Char; ao indicador.
Numérico.
nm Nome Text; Character Armazena dados contendo
Varying; String textos reltivos a dados de
nomenclatura.
nu Número Integer; Int; Armazena informações
Float; numéricas.
Decimal;
Numérico.
qt Quantidade Integer; Int; Armazena informações
Float; quantitativas.
Decimal;
Numérico.
tp Tipo Integer; Int; Armazena dados relativos a
Char; domínio.
Numérico.
vl Valor Valor Armazena dados relativos a
monetário, valores financeiros
Currency,
Decimal, Float,
vs Versão Valor numérico Armazena dados relativos a
versão.
Tabela 3: Tabela de prefixos sugeridos para nomenclatura de objetos e atributos
 nnn → a partir do prefixo, o complemento terá, caso o assunto a que
se refira seja composto, as três primeiras letras do primeira termo, o caracter
undescore e o termo restante na íntegra, por exemplo: nu_sem_ano, como,
número da semana no ano.

Observação: Caso exista assuntos com nomenclatura similar, deve-se

indicar as diferenças que atribuam clareza aos significados.

1.2. PADRÃO DE NOMENCLATURA DE ROTINAS DE CARGA NO

TALEND OPEN STUDIO DATA INTEGRATOR (TOS-DI)

Para a nomenclatura das rotinas de carga, denominadas no contexto

da ferramenta Talend Open Studio Data Integrator (TOS-DI), por job. Sugere-
se empregar o termo ‘job’ unido pelo caractere undescore ‘_’ ao termo ‘carga’ e
mais um undescore ‘_’ unindo tudo ao termo ou termos que identifiquem com
clareza o assundo da carga, por exemplo: job_carga_dm_pes_juridica. Que
quer dizer que se trata do job que carrega a entidade de dados do tipo
dimensão que armazena dados sobre pessoa jurídica.

2. IDENTIFICAÇÃO DE NECESSIDADES
Num processo de desenvolvimento de solução de software
[SOMMERVILE, I. 2011], se faz necessário identificar com precisão os
fundamentos ou pilares básicos para a construção da solução. No caso de,
solução de Business Intelligence - Inteligência de Negócio (BI) é fundamental
que essas definições sejam estritamente negociais, como o próprio nome já
indica, Inteligência Negocial. Esses fundamentos são denominados
Necessidades e estão relacionados aos requisitos Funcionais e Não Funcionais
identificados pelos stakeholders (patrocinadores, usuários etc.) envolvidos no
negócio. Esses fundamentos são as regras fundamentais a serem seguidas
durante a construção da solução. As necessidades fundamentais, identificadas
para o projeto, foram as seguintes:
id Necessidade Observação
1 Identificar os Indicadores Chave (KPI’s) relacionados aos
Contextos.
2 Concepção do Modelo Dimensional para abrigar os
dados dos Indicadores provenientes do DAP e Garantia
Safra.
3 Construção das Rotinas de Carga para carregar DDM’s.
4 Efetivação do processo de carga.
Tabela 4: Lista de Necessidades.

2.1. IDENTIFICAR OS INDICADORES CHAVE DE DESEMPENHO

(KPI) RELACIONADOS Aos contextos.

Utilizou-se, como ponto de partida, a estratégia de se identificar os

indicadores que já são utilizados nos contextos DAP e Garantia Safra como
base incial para a identificação de necessidades fundamentais para a
construção do modelo do DW. Ao identificar esse indicadores partiu-se para a
ampliação do escopo da análise para, o que atualmente, se denomina análise
em 360°, que permite a possibilidade dos dados serem analisados em diversos
ângulos, prismas e comparações.

2.1.1. INDICADORES CHAVE DE DESEMPENHO (KPI’S) RELACIONADOS AO

CONTEXTO DAP

O acrônimo DAP se refere a Declaração de Aptidão ao PRONAF.

Sendo que, PRONAF se refere a Programa Nacional de Fortalecimento da
Agricultura Familiar que conforme [PRONAF, 2018]:

… financia projetos individuais ou coletivos, que gerem

renda aos agricultores familiares e assentados da reforma
agrária.O programa possui as mais baixas taxas de juros dos
financiamentos rurais, além das menores taxas de
inadimplência entre os sistemas de crédito do Pais.

O acesso ao Pronaf inicia-se na discussão da família

 sobre a necessidade do crédito, seja ele para o custeio da
safra ou atividade agroindustrial, seja para o investimento em
máquinas, equipamentos ou infraestrutura de produção e
serviços agropecuários ou não agropecuários.

Após a decisão do que financiar, a família deve

procurar o sindicato rural ou a empresa de Assistência Técnica
e Extensão Rural (Ater), como a Emater, para obtenção da
DAP, que será emitida segundo a renda anual e as atividades
exploradas, direcionando o agricultor para as linhas específicas
de crédito a que tem direito. Para os beneficiários da reforma
agrária e do crédito fundiário, o agricultor deve procurar o
Instituto Nacional de Colonização e Reforma Agrária (Incra) ou
a Unidade Técnica Estadual (UTE).

O agricultor deve estar com o CPF regularizado e livre

de dívidas. As condições de acesso ao Crédito Pronaf, formas
de pagamento e taxas de juros correspondentes a cada linha
são definidas, anualmente, a cada Plano Safra da Agricultura
Familiar, divulgado entre os meses de junho e julho.

Neste contexto, foram identificados os seguintes indicadores chave de

desempenho (KPI’s) que, atualmente, já são utilizados pelo NEAD:

Nome do Indicador (KPI) Definição Métrica

i.1 Número de DAP’s Principais. Quantidade de Declarações qt_dap_princial
de Aptidão ao PRONAF
(DAP) para identificação e
qualificação dos responsáveis
pela Unidade Familiar de
Produção Rural (UFPR)
válidas no período.
i.2 Número de DAP’s Jurídicas. Quantidade de Declarações qt_dap_juridica
de Aptidão ao PRONAF
(DAP) para identificação e
qualificação das formas
associativas de Unidade
Familiar de Produção Rural
(UFPR) válidas no período.
i.3 Número de DAP’s Jovem Quantidade de DAP’s qt_dap_jovem
acessórias para identificação
e qualificação dos(as)
filhos(as) jovens entre 15 e 29
anos dos responsáveis pela
Unidade Familiar de
Produção Rural (UFPR)
válidas no período, que
devem estar obrigatoriamente
vinculada a DAP Principal.
i.4 Número de DAP’s Mulher. Quantidade de DAP’s qt_dap_mulher
acessórias para identificação
e qualificação das mulheres
agregadas a uma Unidade
Familiar de Produção Rural
(UFPR) válidas no período,
que deve estar
obrigatoriamente vinculada a
DAP Principal.
Tabela 5: Indicadores Chave (KPI's) do DAP.

2.1.2. INDICADORES CHAVE DE DESEMPENHO (KPI’S) RELACIONADOS AO

GARANTIA SAFRA

O Garantia-Safra (GS) é uma ação do Programa Nacional de

Fortalecimento da Agricultura Familiar (PRONAF) [SAF, 2018] que:

… inicialmente voltada para os agricultores familiares

que vivem no Nordeste do Brasil e no Norte dos estados de
Minas Gerais e do Espírito Santo. A região é a área de atuação
da Superintendência do Desenvolvimento do Nordeste
(Sudene), majoritariamente semiárida e que sofre perda
sistemática de safra por motivo de seca ou excesso de chuvas.

Com a Lei Nº 12.766, de 27 de dezembro de 2012, o

Poder Executivo foi autorizado a incluir agricultores familiares
de outros municípios situados fora da área da Sudene, desde
que atendidos previamente alguns requisitos como a
comprovação de que os agricultores familiares se encontram
em municípios com perdas sistemáticas de produção em
função da seca ou excesso de chuva.

Beneficiário e Benefício

O Garantia-Safra tem como beneficiários os

agricultores que possuem renda familiar mensal de, no
máximo, 1,5 (um e meio) salário mínimo e que plantam entre
0,6 e 5 hectares de feijão, milho, arroz, mandioca, algodão.

Uma vez aderidos ao programa, eles passam a receber

o benefício quando o município em que moram comprova
perda de, pelo menos, 50% do conjunto dessas produções, ou
de outras a serem definidas pelo órgão gestor do Fundo
Garantia-Safra, em razão de estiagem ou excesso hídrico.

O valor do Benefício Garantia-Safra e a quantidade de

agricultores a serem segurados pelo GS são definidos
anualmente durante a reunião do Comitê Gestor do Garantia-
Safra.

Atualmente, o valor do benefício é igual a R$ 850,00,

pago em cinco parcelas de R$ 170,00 por meio de cartões
eletrônicos disponibilizados pela Caixa Econômica Federal de
acordo com o calendário de benefícios sociais. A medida é uma
forma de contribuir para segurança alimentar da família do
agricultor, o que dá liberdade para que ele escolha como
aplicar o dinheiro.

Aportes

Para que o agricultor participe é necessário que,

anualmente, estados, municípios e agricultores façam adesão
ao programa por meio da inscrição e pagamento anual dos
aportes que tem valores iguais a R$ 17,00 para agricultores; a
R$ 51,00 para os municípios; a R$ 102,00 para os estados; e a
R$ 340,00, no mínimo, para a União.
 Vale ressaltar que os aportes totais municipais, federais
e estaduais são resultados da multiplicação do valor do aporte
pelo número total de agricultores aderidos ao programa em
cada esfera…

Os produtores só recebem o benefício se todas as partes repassarem o

recurso ao Fundo de Garantia-Safra e se a perda de ao menos 50% da produção for
comprovada pelo município.

Neste contexto, foram identificados os indicadores chaves (KPI’s)

que, atualmente, já são utilizados pela NEAD:

Nome do Indicador Definição Métrica

(KPI)
i.5 Quantidade de Quantidade de agricultores que qt_agr_adr_gs
agricultores aderidos aderiram ao programa Garantia Safra
ao Garantia-Safra
i.6 Quantidade de Quantidade de agricultores qt_agr_ben_gs
agricultores beneficiados pelo programa Garantia
beneficiados pelo Safra
Garantia Safra
i.7 Valor pago (R$) pelo Valor total do pagamento do benefício vl_pag_gs
Garantia Safra do Garantia Safra realizado aos
agricultores
i.8 Número de Quantidade de municípios aderidos ao qt_mun_adr_gs
municípios aderidos Garantia Safra.
ao Garantia Safra
Tabela 6: Indicadores Chave (KPI's) do Garantia Safra

2.2. CONCEPÇÃO DE MODELO DIMENSIONAL PARA ABRIGAR OS

DADOS DOS INDICADORES CHAVE DE DESEMPENHO
IDENTIFICADOS

Após a identificação dos Indicadores Chave de Desempenho (KPI’s)

referentes aos contextos DAP e GARANTIA SAFRA, partiu-se para a
construção de um modelo dimensional que fosse capaz de abrigar os dados
necessários para atender as respostas esperadas por esses indicadores e já
prevendo a ampliação do escopo de análise.
 O conjunto de modelos dimensionais que formam o que se denomina
Armazém de Dados, ou DW do acrônimo Data Warehouse [Inmon, W. H.,
1999] é composto por estruturas dimensionais segregadas por assunto e que é
conhecida por DDM, ou seja, DataMart [Kimball, R.; Caserta, J., 2011].

2.2.1. GRANULARIDADE
Inicialmente, antes de abordar o que seja DDM é necessário esclarecer
o que seja granularidade dos dados. Esse termo se refere ao menor grão que
se refere o dado armazenado na tabela fato. Por exemplo: digamos que exista
na tabela fato de um DDM, dados relativos a quantidade de DAP’s
armazenadas num determinado dia do ano. A granularidade desta informação,
ou seja, o menor grão possível para a construção desta informação é o dia. Se
for indagado ao sistema quantas DAP’s foram registradas num mês o sistema
aplicará a agregação a partir da soma das quantidades granulares, ou seja, a
quantidade de DAP’s por dia.

2.2.2. DDM - DATA MART

Os DDM’s [Kimball, R. & Ross, M., 2013], são particulas fundamentais
de dados orientados por assunto e constituídos por dois tipos distintos de
entidades de dados, que são:

a) Dimensões – entidade de dados que armazenam atributos que se

referem a possíveis questões que podem ser submetidas a um modelo, ou
seja, tomando-se como exemplo a dimensão tempo, que segundo o padrão de
nomenclatura deste projeto, seria identificada como: dm_tempo, pode submeter
ao modelo questões temporais, ou seja, o que aconteceu em termos
quantitativos num determinado período temporal cujos atributos armazenados
nesta dimensão se refiram, por exemplo, a qual o valor do movimento num
determinado dia ou mês ou quinzena ou ano e a métrica ou medida associada
a essa dimensão temporal e armazenada no entidade de dados do tipo fato
será agregada de acordo com a temporalidade pesquisada e associada ao
grão do dado;

b) Fato – por outro lado, nas entidades definidas como fatos são
armazenados aos eventos, principalmente, quantitativos relacionados as
dimensões.
 Existem basicamente, dois tipos de modelos dimensionais:

i) Estrela – que é um modelo onde existe uma relação direta entre as

dimensões (DM) e a fato (FT). Sugerindo o formato de uma estrela;

ii) Snow Flake ou Floco de Neve – que é um modelo derivado em que

existe dimensões (DM) ligadas a fato (FT) e dimensões (DM) ligadas a outras
dimensões (DM).

Observação: Teoricamente, cada fato (FT) e as suas interligações com

as dimensões (DM) define um data mart (DDM). Para cada uma das fatos
devem existir uma granularidade definida. Desta feita, foram identificados os
seguintes DDM’s:

ID NOME DO DDM INDICADORES (KPI’s) MÉTRICA GRÃO

1 DDM_SOCIOS_D Número de DAP’s - qt_dap_juridica - Sócios
AP_JURIDICA Juridicas.
2 Número de DAP’s - qt_dap_principal - Titular
Principais.
DDM_TITULAR_ Número de DAPs de - qt_dap_jovem
DAP Jovens
Número de DAP’s de - qt_dap_mulher
Mulher
3 DDM_INSCRICO - Número de Municípios - vl_aporte;
ES_GS aderidos ao GS; - qt_safristas
- Valor do aporte pelo - qt_municipios
Município ao GS; aderiram –
- Quantidade de métrica derivada - Agricultor
Agricultores Aderidos; pelo somatório de
- Quantidade de municípios.
Agricultores Beneficiados.

4 DDM_BENEFICIA - Quantidade de - qt_beneficiados - Agricultores

RIOS_GS Agricultores Beneficiados
Tabela 7: Lista dos DataMart's (DDM) iniciais do projeto.

2.3. DATAMART’S DEFINIDOS PARA O ARMAZÉM DE DADOS

Mediante a análise das necessidades, requisitos e dados

disponibilizados nas fontes originárias definiu-se o modelo dimensional do
Armazém de Dados (DW) de forma que atenda as necessidades do projeto.
Desta feita, foram definidos os seguintes Data Mart’s (DDM’s):

a) DDM_SOCIOS_DAP_JURIDICA: Data Mart composto pela fato

ft_socios_dap_juridica - que armazena os dados referentes aos sócios das
DAP’s Jurídicas, tendo como granularidade os dados referentes aos sócios que
compõem a DAP. A métrica derivada qt_dap_juridica, obtida a partir da soma
distinta do atributo cd_dap correlacionada ao filtro de agregação definido. Este
modelo responde ao indicador 2. Número de DAP jurídica;

b) DDM_TITULAR_DAP: Data Mart composto pela fato ft_titular_dap –

que armazena os dados referentes aos titulares das DAP’s, tendo como
granularidade o titular de DAP. As métrica envolvidas são: a) qt_dap_principal
– métrica derivada, construida a partir da agregação distinta dos cd_dap; b)
qt_dap_jovem – métrica derivada, construída a partir da agregação distinta dos
cd_dap filtradas pelo id_tip_dap, cuja valor seja e c) qt_dap_mulher – métrica
derivada, constituída a partir da agregação distinta dos id_com_dap filtradas
por um dos titulares de sexo feminino. Este modelo responde aos indicadores:
1. Número de DAP Principal; 3. Número de DAP’s Jovem; 4. Número de DAP
Mulher;

c) DDM_INSCRICOES_GS: Data Mart composto pela fato

ft_inscricoes_gs – que armazena os dados referentes as inscrições no
programa Garantia Safra, tendo como granularidade os agricultores que se
cadidataram ao programa Garantia Safra. As métricas envolvidas são: a)
qt_inscrições – quantidade de inscrições que se candidatam ao programa; b)
qt_aderidos – quantidade de agricultores que efetivaram a adesão ao
programa; c) qt_municipios – quantidade de municípios inscritos no programa.
Este modelo responde aos indicadores: 5. Quantidade de agricultores aderidos
ao Garantia Safra; 6. Quantidade de agricultores beneficiados pelo Garantia
Safra; 7. Valor total arrecadado pelo Garantia Safra e 8. Número de municípios
aderidos ao Garantia Safra.

d) DDM_BENEFICIADOS_GS: Data Mart composto pelas fatos

ft_beneficiados_gs – que armazena os dados referentes aos agricultores que
foram beneficiados pelo programa Garantia Safra, tendo como granularidade
os Agricultores beneficiados. A métricas envolvidas são: qt_beneficiados.
 2.4. IMAGEM DO MODELO DE DADOS CONCEITUAL DO
ARMAZÉM DE DADOS PROPOSTO PARA ESTOCAGEM DOS
DADOS REFERENTES AOS INDICADORES CHAVES DO DAP E
GARANTIA SAFRA

Figura 1: Modelo de Dados Dimensionais do DW

2.5. DESCRIÇÃO DO MODELO DIMENSIONAL PROPOSTO PARA O

ARMAZÉM DE DADOS (DW)

O modelo proposto tem por característica principal ser incremental, ou

seja, conforme novos indicadores forem sendo acrescidos a lista inicial o
 modelo pode ser atualizado para responder às novas necessidades. Esse
modelo se compõem das seguintes entidades de dados:

Esse modelo se compõe inicialmente de entidades de dois tipos, que são:

a) Dimensões:

1. dm_pessoa_juridica → entidade de dados que armazena as pessoas

jurídicas com as quais existem alguma referência negocial nos datamart’s
(DDM’s). Essa entidade armazena tanto pessoas jurídicas que detém DAP’s,
por exemplo, quanto entidades autorizadas a emití-las entre outros;

2. dm_municipio → entidade de dados que armazena os municípios,

unidades da federação (UF’s) e Regiões com as quais existam referências
negociais nos DDM’s;

3. dm_tipo_dap → entidade de dados que armazena os domínios

referentes aos tipos de DAP’s existentes nos contextos;

4. dm_pessoa_fisica → entidade de dados que armazena toda e

qualquer pessoa física referenciadas nos DDM’s;

5. dm_enquadramento → entidade de dados que armazena os tipos de

enquadramento das DAP’s;

6. dm_dap_juridica → entidade de dados que armazena as referências

as DAP’s jurídicas referenciadas pelos DDM’s;

7. dm_data → entidade de dados que armazena as datas referenciadas

por pesquisa que existam nos DDM’s.

b) Fatos:

1) ft_socios_dap_juridica → entidade de dados que armazena as ocorrências

relacionadas aos sócios que compõe uma DAP jurídica. O grão é o sócio;

2) ft_titular_dap → entidade de dados que armazena as ocorrências

relacionadas aos titulares de uma DAP que não seja jurídica. O grão é o titular;
 3) ft_beneficiarios_gs → entidade de dados que armazena as ocorrências
relacionadas aos beneficiários do programa Garantia Safra, sendo que a
granularidade desse DDM é o agricultor que obteve o benefício para uma
determinada safra;

4) ft_inscricoes_gs → entidade de dados que armazena as ocorrências relacionadas

às inscrições para o programa Garantia Safra. Por intermédio desta fato e do
st_adesao é possível saber se o inscrito aderiu ao programa efetivando o
pagamento.

2.5.1. DEFINIÇÃO DOS DDM’s

1. DDM_SOCIOS_DAP_JURIDICA: por intermédio deste Data

Mart é possível obter a quantidade de sócios pessoas físicas que fazem parte
de uma determinada DAP jurídica, as DAP’s jurídicas relacionadas as pessoas
jurídicas e sua localização geográfica. Além da quantidade de DAP’s jurídicas
existentes. Esse modelo por ser incremental pode ser desenvolvido para
possibilitar outras análises.

Figura 2: DDM_SOCIOS_DAP_JURIDICA
 2. DDM_TITULAR_DAP: com este data mart é possível inferir a
quantidade de DAP’s pela contabilização distintas do cd_dap da fato e
identificar o tipo de titularidade do titular. Bem como, classificar como
dap_mulher, dap_jovem ou dap_principal. Como todos os outros DDM’s, este
também é evolutivo e pode ser acrescidas novas relações.

Figura 3: DDM_TITULAR_DAP
 3. DDM_INSCRICOES_GS: Este DDM armazena as ocorrências das
inscrições ao programa Garantia Safra, sendo possível acompanhar por
intermédio do atributo st_adesao se a inscrição se transformou em adesão e
qual o valor pago, bem como, a data do pagamento. Pelo atributo
st_beneficiario é possível identificar se o agricultor relacionado a inscrição foi
beneficiado.

Figura 4: DDM_INSCRICOES_GS
 4. DDM_BENEFICIARIOS_GS: Neste DDM os dados acomodados na
fato, tendo como granularidade o agricultor beneficiário do Garantia Safra,
permite a identificação da localidade desse agricultor e informações, tais como,
gênero (sexo), naturalidade, município, uf e região do beneficiado.

Figura 5: DDM_BENEFICIARIOS_GS

2.6. CONSTRUÇÃO DA SOLUÇÃO

Concluída a concepção da solução, deu início a efetiva criação do

modelo dimensional e ao processo de popular as entidades de dados criadas.
O script de criação de entidade de dados do modelo foi aplicado no SGBD EBD
PostgreSQL [Dar, U et all, 2015] a partir do concepção conceitual na
ferramenta Power Architect [Architect, 2018] gerou-se um script para
concepção das entidades de dados.
 2.7. SCRIPT GERADO PELA FERRAMENTA SQL POWER
ARCHTECT PARA CRIAÇÃO DAS ENTIDADES DE DADOS DOS
DDM’S QUE COMPÕEM O DW

CREATE SEQUENCE ft_titular_dap_id_tit_dap_seq;

CREATE TABLE ft_titular_dap (

id_tit_dap INTEGER DEFAULT nextval('nead.ft_titular_dap_id_tit_dap_seq'::regclass) NOT NULL DEFAULT

nextval('ft_titular_dap_id_tit_dap_seq'),

cd_cpf_titular CHAR(11) NOT NULL,

cd_dap CHAR(25) NOT NULL,

id_tip_dap INTEGER NOT NULL,

dt_validade DATE,

id_dap_mulher CHAR(1),

CONSTRAINT ft_titular_dap_pk PRIMARY KEY (id_tit_dap)

);

COMMENT ON TABLE ft_titular_dap IS 'Entidade de Dados do Tipo Fato que armazena os titulares das DAP''s de
Pessoa Física.';

COMMENT ON COLUMN ft_titular_dap.id_tit_dap IS 'Identificador do titular da DAP. Chave primária artificial';

COMMENT ON COLUMN ft_titular_dap.cd_cpf_titular IS 'Código de Pessoa Física do títular na Receita Federal';

COMMENT ON COLUMN ft_titular_dap.cd_dap IS 'Código da DAP. Chave estrangeira com a tabela

dm_dap_pessoa_fisica';

COMMENT ON COLUMN ft_titular_dap.id_tip_dap IS 'Identificador do Tipo de DAP. Domínios: 1 - DAP Principal; 2 -

DAP Agregada; 3 DAP Jovem.';

COMMENT ON COLUMN ft_titular_dap.dt_validade IS 'Data de Validade';

COMMENT ON COLUMN ft_titular_dap.id_dap_mulher IS 'Identificador de DAP Mulher.';

ALTER SEQUENCE ft_titular_dap_id_tit_dap_seq OWNED BY ft_titular_dap.id_tit_dap;

CREATE SEQUENCE ft_socios_dap_juridica_id_socio_seq;

CREATE TABLE ft_socios_dap_juridica (

 id_socio INTEGER DEFAULT nextval('nead.ft_socios_dap_juridica_id_socio_seq'::regclass) NOT NULL
DEFAULT nextval('ft_socios_dap_juridica_id_socio_seq'),

cd_cpf_socio VARCHAR(11) NOT NULL,

dt_filiacao DATE,

cd_dap VARCHAR(25),

sg_enquadramento VARCHAR(10),

id_dap_retirada INTEGER,

CONSTRAINT ft_socios_dap_pj_pk PRIMARY KEY (id_socio)

);

COMMENT ON TABLE ft_socios_dap_juridica IS 'Entidade de Dados do Tipo Fato que armazena DAP de Jovem.';

COMMENT ON COLUMN ft_socios_dap_juridica.id_socio IS 'Identificador do Sócio. Chave primária artificial';

COMMENT ON COLUMN ft_socios_dap_juridica.cd_cpf_socio IS 'Código do CPF Sócio';

COMMENT ON COLUMN ft_socios_dap_juridica.dt_filiacao IS 'Data de Filiação';

COMMENT ON COLUMN ft_socios_dap_juridica.cd_dap IS 'Código DAP';

COMMENT ON COLUMN ft_socios_dap_juridica.sg_enquadramento IS 'Sigla de Enquadramento';

COMMENT ON COLUMN ft_socios_dap_juridica.id_dap_retirada IS 'Identificador de DAP Retirada';

ALTER SEQUENCE ft_socios_dap_juridica_id_socio_seq OWNED BY ft_socios_dap_juridica.id_socio;

CREATE SEQUENCE ft_inscricoes_gs_id_inscricao_seq;

CREATE TABLE ft_inscricoes_gs (

id_inscricao INTEGER DEFAULT nextval('nead.ft_inscricoes_gs_id_inscricao_seq'::regclass) NOT NULL DE -

FAULT nextval('ft_inscricoes_gs_id_inscricao_seq'),

cd_ins_ger_gs INTEGER,

cd_cdda INTEGER,

nu_ano_programa INTEGER,

cd_mun_ibge INTEGER,

id_agr_familiar INTEGER,

id_potencial INTEGER,
 st_beneficiario INTEGER,

cd_cpf_inscricao VARCHAR(2147483647),

tp_tit_dap VARCHAR(2147483647),

st_adesao INTEGER,

vl_pago NUMERIC(9,2),

dt_pagamento DATE,

CONSTRAINT ft_inscricoes_gs_pk PRIMARY KEY (id_inscricao)

);

COMMENT ON TABLE ft_inscricoes_gs IS 'Entidade de Dados do Tipo Fato que armazena as Inscrições ao Programa
Garantia Safra.';

COMMENT ON COLUMN ft_inscricoes_gs.id_inscricao IS 'Identificador da Inscrição. Chave primária artificial';

COMMENT ON COLUMN ft_inscricoes_gs.cd_ins_ger_gs IS 'Código da Inscrição no Programa Garantia Safra.';

COMMENT ON COLUMN ft_inscricoes_gs.cd_cdda IS 'Código CDDA';

COMMENT ON COLUMN ft_inscricoes_gs.nu_ano_programa IS 'Ano do Programa da Inscrição no Garantia Safra';

COMMENT ON COLUMN ft_inscricoes_gs.cd_mun_ibge IS 'Código do Município de Inscrição no IBGE.';

COMMENT ON COLUMN ft_inscricoes_gs.id_potencial IS 'Identificador do Potencial da Inscrição em conseguir o

benefício';

COMMENT ON COLUMN ft_inscricoes_gs.st_beneficiario IS 'Código de Situação do Beneficiário.';

COMMENT ON COLUMN ft_inscricoes_gs.cd_cpf_inscricao IS 'Código de Pessoa Física na Receita Federal';

COMMENT ON COLUMN ft_inscricoes_gs.st_adesao IS 'Sinalizador de Adesão confirmada com pagamento';

COMMENT ON COLUMN ft_inscricoes_gs.vl_pago IS 'Valor paga para adesão.';

COMMENT ON COLUMN ft_inscricoes_gs.dt_pagamento IS 'Data de Pagamento da Adesão';

ALTER SEQUENCE ft_inscricoes_gs_id_inscricao_seq OWNED BY ft_inscricoes_gs.id_inscricao;

CREATE SEQUENCE ft_beneficiarios_gs_id_beneficiario_seq;

CREATE TABLE ft_beneficiarios_gs (

id_beneficiario INTEGER DEFAULT nextval('nead.ft_beneficiarios_gs_id_beneficiario_seq'::regclass) NOT

NULL DEFAULT nextval('ft_beneficiarios_gs_id_beneficiario_seq'),

cd_ins_ger_gs INTEGER,
 cd_cdda INTEGER,

nu_ano_programa INTEGER,

cd_mun_ibge INTEGER,

id_agr_familiar INTEGER,

cd_cpf_inscricao VARCHAR(2147483647),

tp_tit_dap VARCHAR(2147483647),

CONSTRAINT ft_beneficiarios_gs_pk PRIMARY KEY (id_beneficiario)

);

COMMENT ON TABLE ft_beneficiarios_gs IS 'Entidade de Dados do Tipo Fato que armazena as Inscrições ao
Programa Garantia Safra.';

COMMENT ON COLUMN ft_beneficiarios_gs.id_beneficiario IS 'Identificador do Beneficiário. Chave primária artificial';

COMMENT ON COLUMN ft_beneficiarios_gs.cd_ins_ger_gs IS 'Código da Inscrição no Programa Garantia Safra.

Chave primária natural';

COMMENT ON COLUMN ft_beneficiarios_gs.cd_cdda IS 'Código CDDA';

COMMENT ON COLUMN ft_beneficiarios_gs.nu_ano_programa IS 'Ano do Programa da Inscrição no Garantia Safra';

COMMENT ON COLUMN ft_beneficiarios_gs.cd_mun_ibge IS 'Código do Município de Inscrição no IBGE.';

COMMENT ON COLUMN ft_beneficiarios_gs.cd_cpf_inscricao IS 'Código de Pessoa Física na Receita Federal';

COMMENT ON COLUMN ft_beneficiarios_gs.tp_tit_dap IS 'Tipo de titularidade na DAP.';

ALTER SEQUENCE ft_beneficiarios_gs_id_beneficiario_seq OWNED BY ft_beneficiarios_gs.id_beneficiario;

CREATE TABLE dm_tipo_dap (

cd_tip_dap INTEGER NOT NULL,

nm_tip_dap VARCHAR(2147483647) NOT NULL,

CONSTRAINT dm_tipo_dap_pk PRIMARY KEY (cd_tip_dap)

);

COMMENT ON TABLE dm_tipo_dap IS 'Entidade de Dados do Tipo Dimensão que armazena os tipos de DAP';

COMMENT ON COLUMN dm_tipo_dap.cd_tip_dap IS 'Código do Tipo de DAP.';

COMMENT ON COLUMN dm_tipo_dap.nm_tip_dap IS 'Nome do Tipo da DAP.';

CREATE TABLE dm_pessoa_juridica (

cd_esp_cnpj CHAR(14) NOT NULL,

cd_cnpj CHAR(14) NOT NULL,

nm_rz_social VARCHAR(110) NOT NULL,

nm_fantasia VARCHAR(80),

dt_constituicao DATE,

cd_ins_estadual VARCHAR(20),

CONSTRAINT dm_pessoa_juridica_pk PRIMARY KEY (cd_esp_cnpj)

);

COMMENT ON TABLE dm_pessoa_juridica IS 'Entidade de Dados do tipo dimensão que armazena as pessoas
jurídicas.';

COMMENT ON COLUMN dm_pessoa_juridica.cd_esp_cnpj IS 'Código Específico de Pessoas Jurídicas da Receita

Federal. Chave Primária Natural';

COMMENT ON COLUMN dm_pessoa_juridica.cd_cnpj IS 'Código de Pessoas Jurídicas da Receita Federal.';

COMMENT ON COLUMN dm_pessoa_juridica.nm_rz_social IS 'Razão Social da Pessoa Jurídica.';

COMMENT ON COLUMN dm_pessoa_juridica.nm_fantasia IS 'Nome Fantasia da Pessoa Jurídica.';

COMMENT ON COLUMN dm_pessoa_juridica.dt_constituicao IS 'Data de Constituição da Pessoa Jurídica.';

COMMENT ON COLUMN dm_pessoa_juridica.cd_ins_estadual IS 'Código da Inscrição Estadual da Pessoa Jurídica.';

CREATE TABLE dm_pessoa_fisica (

id_pes_fisica INTEGER NOT NULL,

cd_cpf CHAR(11),

nm_pes_fisica VARCHAR(80),

nm_mae VARCHAR(80),

dt_nascimento DATE,

cd_rg VARCHAR(20),

uf_org_emissor CHAR(2),

tp_sexo VARCHAR(10),

tp_est_civil VARCHAR(20),
 cd_mun_naturalidade INTEGER,

CONSTRAINT dm_pessoa_fisica_pk PRIMARY KEY (id_pes_fisica)

);

COMMENT ON TABLE dm_pessoa_fisica IS 'Entidade de dados que armazena as pessoas físicas.';

COMMENT ON COLUMN dm_pessoa_fisica.id_pes_fisica IS 'Identificador de Pessoa Física. Chave Natural derivada da

Tabela TBPES_Fisica do BD de origem.';

COMMENT ON COLUMN dm_pessoa_fisica.cd_cpf IS 'Código de Pessoa Física da Receita Federal.';

COMMENT ON COLUMN dm_pessoa_fisica.nm_pes_fisica IS 'Nome da Pessoa Física.';

COMMENT ON COLUMN dm_pessoa_fisica.nm_mae IS 'Nome da Mãe da Pessoa Física.';

COMMENT ON COLUMN dm_pessoa_fisica.dt_nascimento IS 'Data de Nascimento da pessoa física.';

COMMENT ON COLUMN dm_pessoa_fisica.cd_rg IS 'Código do Registro Geral da Secretaria de Segurança da pessoa

física.';

COMMENT ON COLUMN dm_pessoa_fisica.uf_org_emissor IS 'UF do Orgão Emissor do RG.';

COMMENT ON COLUMN dm_pessoa_fisica.tp_sexo IS 'Sexo (gênero) da Pessoa Física.';

COMMENT ON COLUMN dm_pessoa_fisica.tp_est_civil IS 'Estado Civil da Pessoa Física';

COMMENT ON COLUMN dm_pessoa_fisica.cd_mun_naturalidade IS 'Código do Município de naturalidade da Pessoa

Física';

CREATE TABLE dm_municipio (

cd_mun_ibge CHAR(7) NOT NULL,

nm_municipio VARCHAR(80) NOT NULL,

nm_mun_sem_acento VARCHAR(80) NOT NULL,

cd_uf CHAR(2) NOT NULL,

sg_uf CHAR(2) NOT NULL,

nm_uf VARCHAR(80) NOT NULL,

CONSTRAINT dm_municipio_pk PRIMARY KEY (cd_mun_ibge)

);

COMMENT ON TABLE dm_municipio IS 'Entidade de Dados do tipo dimensão que armazena dados sobre os
municípios brasileiros.';

COMMENT ON COLUMN dm_municipio.cd_mun_ibge IS 'Código do Município no IBGE';

COMMENT ON COLUMN dm_municipio.nm_municipio IS 'Nome do Município';

COMMENT ON COLUMN dm_municipio.nm_mun_sem_acento IS 'Nome do Município sem Acento';

COMMENT ON COLUMN dm_municipio.cd_uf IS 'Código da Unidade da Federação';

COMMENT ON COLUMN dm_municipio.sg_uf IS 'Sigla da Unidade da Federação';

COMMENT ON COLUMN dm_municipio.nm_uf IS 'Nome da Unidade da Federação';

CREATE SEQUENCE dm_enquadramento_id_enquadramento_seq;

CREATE TABLE dm_enquadramento (

id_enquadramento INTEGER DEFAULT nextval('nead.dm_enquadramento_id_enquadramento_seq'::regclass)

NOT NULL DEFAULT nextval('dm_enquadramento_id_enquadramento_seq'),

cd_enquadramento INTEGER NOT NULL,

ds_enquadramento VARCHAR(20) NOT NULL,

sg_enquadramento VARCHAR(5),

sg_enq_geral VARCHAR(5),

CONSTRAINT dm_enquadramento_pk PRIMARY KEY (id_enquadramento)

);

COMMENT ON TABLE dm_enquadramento IS 'Entidade de Dados do Tipo Dimensão que armazena os

Enquadramentos de DAP.';

COMMENT ON COLUMN dm_enquadramento.id_enquadramento IS 'Identificador do Enquadramento. Chave primária

artificial';

COMMENT ON COLUMN dm_enquadramento.cd_enquadramento IS 'Código do Enmquadramento';

COMMENT ON COLUMN dm_enquadramento.ds_enquadramento IS 'Descrição do Enquadramento';

COMMENT ON COLUMN dm_enquadramento.sg_enquadramento IS 'Sigla do Enquadramento';

COMMENT ON COLUMN dm_enquadramento.sg_enq_geral IS 'Sigla de Enquadramentom Geral';

ALTER SEQUENCE dm_enquadramento_id_enquadramento_seq OWNED BY dm_enquadramento.id_enquadramento;

CREATE TABLE dm_data (

sk_data INTEGER NOT NULL,

data DATE,
 nu_dia INTEGER,

nu_mes INTEGER,

nu_sem_ano INTEGER,

nu_sem_mes INTEGER,

nu_dia_semana INTEGER,

nu_ano INTEGER,

nm_mes VARCHAR(9),

nm_ano_mes_abrev CHAR(7),

nu_ano_mes INTEGER,

nm_mes_abrev CHAR(3),

nm_dia_semana VARCHAR(7),

nu_dia_ano INTEGER,

nu_bimestre INTEGER,

nu_trimestre INTEGER,

nu_semestre INTEGER,

id_dia_util INTEGER,

id_fim_semana INTEGER,

ds_dat_extenso VARCHAR(50),

CONSTRAINT id_data_pk PRIMARY KEY (sk_data)

);

CREATE TABLE dm_dap_juridica (

cd_dap CHAR(25) NOT NULL,

cd_cnpj CHAR(14) NOT NULL,

cd_ver_dap NUMERIC(131089) NOT NULL,

nu_ano NUMERIC(131089) NOT NULL,

cd_cpf_responsavel CHAR(11) NOT NULL,

cd_mun_sede NUMERIC(131089) NOT NULL,

dt_validade DATE NOT NULL,

 cd_enquadramento INTEGER NOT NULL,

CONSTRAINT dm_dap_juridica_pk PRIMARY KEY (cd_dap)

);

COMMENT ON TABLE dm_dap_juridica IS 'Entidade de Dados do Tipo Dimensão que armazena as DAP''s Juridicas.';

COMMENT ON COLUMN dm_dap_juridica.cd_dap IS 'Código da DAP. Chave Primária Natural.';

COMMENT ON COLUMN dm_dap_juridica.cd_cnpj IS 'Código da Pessoa Jurídica na Secretaria de Receita Federal.';

COMMENT ON COLUMN dm_dap_juridica.cd_ver_dap IS 'Código da Versão da DAP.';

COMMENT ON COLUMN dm_dap_juridica.nu_ano IS 'Número do Ano da DAP.';

COMMENT ON COLUMN dm_dap_juridica.cd_cpf_responsavel IS 'Código de Pessoa Física do Responsável.';

COMMENT ON COLUMN dm_dap_juridica.cd_mun_sede IS 'Código do Município Sede no IBGE.';

COMMENT ON COLUMN dm_dap_juridica.dt_validade IS 'Data de Validade.';

COMMENT ON COLUMN dm_dap_juridica.cd_enquadramento IS 'Código do Enquadramento';

2.8. CONSTRUÇÃO Das rotinas DE CARGA NA FERRAMENTA

TALEND OPEN STUDIO DATA INTEGRATOR (TOS-DI)

A etapa seguinte constituiu na construção de rotinas de carga para

integrar os dados a partir das origens com destino para as entidades de dados
que compõe o DW. Para as cargas das dimensões foram utilizados as
seguintes rotinas:

1. DM_DATA: entidade de dados do tipo dimensão que armazena as

datas utilizadas no DW e permitindo análise temporal com diversos níveis de
hierarquização. A carga para dimensão data foi concretizada a partir da
execução de script DM_DATA.sql, que gerou as datas, segundo a estrutura da
tabela, e num range coordenado a partir dos parâmetros de data de início e
data fim. Conforme o conteúdo abaixo:
CREATE TABLE nead.dm_data

sk_data int not null,

data date,

nu_dia int,

nu_mes int,

nu_sem_ano int,

nu_sem_mes int,

nu_dia_semana int,

nu_ano int,

nm_mes varchar(9),

nm_ano_mes_abrev char(7),

nu_ano_mes int,

nm_mes_abrev char(3),

nm_dia_semana varchar(7),

nu_dia_ano int,

nu_bimestre int,

nu_trimestre int,

nu_semestre int,

id_dia_util int,

id_fim_semana int,

ds_dat_extenso varchar(50),

constraint id_data_pk PRIMARY KEY (sk_data)

);

CREATE OR REPLACE FUNCTION carregarData(dataini date, datafim date)

RETURNS VARCHAR AS

$$

DECLARE

_sk_data int;
 _data date;

_nu_dia int;

_nu_dia_semana int;

_nm_dia_semana varchar(7);

_nu_ano int;

_nu_mes int;

_nu_ano_mes int;

_nu_dia_ano int;

_nm_mes varchar(9);

_nm_mes_abrev varchar(3);

_nm_ano_mes_abrev char(7);

_nu_bimestre int;

_nu_trimestre int;

_nu_semestre int;

_id_dia_util int;

_id_fim_semana int;

_nu_sem_mes int;

_nu_sem_ano int;

_ds_dat_extenso varchar(50);

BEGIN

WHILE dataini <= datafim LOOP

_sk_data := cast(trim(replace(cast(dataini as varchar(10)),'-','' )) as integer);

_data := cast(cast(dataini as varchar(10))as date);

_nu_dia := extract(day from dataini);

_nu_sem_ano := extract(week from dataini);

_nu_dia_semana := extract(dow from dataini);

_nu_ano := extract(year from dataini);

_nu_mes := extract(month from dataini);

_nm_ano_mes_abrev := cast(dataini as char(7));

_nu_trimestre := extract(quarter from dataini);

_nu_ano_mes := cast(trim(replace(cast(dataini as char(7)),'-','')) as integer);

_nu_dia_ano := extract(doy from dataini);

_nm_dia_semana := case _nu_dia_semana when 1 then 'domingo'

when 2 then 'segunda'

when 3 then 'terça'

when 4 then 'quarta'

when 5 then 'quinta'

when 6 then 'sexta'

when 0 then 'sábado' end;

_nm_mes := case _nu_mes when 1 then 'janeiro'

when 2 then 'fevereiro'

when 3 then 'março'

when 4 then 'abril'

when 5 then 'maio'

when 6 then 'junho'

when 7 then 'julho'

when 8 then 'agosto'

when 9 then 'setembro'

when 10 then 'outubro'

when 11 then 'novembro'

when 12 then 'dezembro' end;

_nm_mes_abrev := case _nu_mes when 1 then 'jan'

when 2 then 'fev'

when 3 then 'mar'

when 4 then 'abr'

when 5 then 'mai'

when 6 then 'jun'

when 7 then 'jul'

 when 8 then 'ago'

when 9 then 'set'

when 10 then 'out'

when 11 then 'nov'

when 12 then 'dez' end;

_nu_bimestre := case when _nu_mes <= 2 then 1

when _nu_mes <= 4 then 2

when _nu_mes <= 6 then 3

when _nu_mes <= 8 then 4

when _nu_mes <= 10 then 5

when _nu_mes <= 12 then 6 end;

_nu_semestre := case when _nu_mes <= 6 then 1

when _nu_mes <= 12 then 2 end;

_nu_sem_mes := case when _nu_dia < 8 then 1

when _nu_dia < 15 then 2

when _nu_dia < 22 then 3

when _nu_dia < 29 then 4

when _nu_dia >= 29 then 5 end;

_id_fim_semana := case when (_nu_dia_semana = 1 or _nu_dia_semana = 0) then 1 end;

_id_dia_util := case when _id_fim_semana = 1 then 0

when (_nu_mes = 1 and _nu_dia = 1) then 0

when (_nu_mes = 4 and _nu_dia = 21) then 0

when (_nu_mes = 5 and _nu_dia = 1) then 0

when (_nu_mes = 9 and _nu_dia = 7) then 0

when (_nu_mes = 10 and _nu_dia = 12) then 0

when (_nu_mes = 11 and _nu_dia = 2) then 0

 when (_nu_mes = 11 and _nu_dia = 15) then 0

when (_nu_mes = 12 and _nu_dia = 25) then 0 end;

_ds_dat_extenso := CONCAT(_nm_dia_semana, cast(', dia ' as varchar), cast(_nu_dia as

varchar), cast(' de ' as varchar ) , _nm_mes, cast(' de ' as varchar), cast(_nu_ano as varchar));

INSERT INTO nead.dm_data(sk_data, data, nu_dia, nu_mes, nu_sem_ano, nu_sem_mes,

nu_dia_semana, nu_ano, nm_mes, nm_ano_mes_abrev, nu_ano_mes, nm_mes_abrev, nm_dia_semana,
nu_dia_ano, nu_bimestre, nu_trimestre, nu_semestre, id_fim_semana, id_dia_util, ds_dat_extenso)

VALUES(_sk_data, _data, _nu_dia, _nu_mes, _nu_sem_ano, _nu_sem_mes, _nu_dia_semana,

_nu_ano, _nm_mes, _nm_ano_mes_abrev, _nu_ano_mes, _nm_mes_abrev, _nm_dia_semana, _nu_dia_ano,
_nu_bimestre, _nu_trimestre, _nu_semestre, coalesce(_id_fim_semana, 0), coalesce(_id_dia_util, 1),
_ds_dat_extenso);

dataini := dataini + 1;

END LOOP;

RETURN 'insert';

END;

$$ language plpgsql;

DO $$ BEGIN

PERFORM carregarData(cast('2010-01-01' as date), cast('2020-12-31' as date));

END $$;
 2. DM_MUNICIPIO: entidade de dados do tipo dimensão que armazena
as localidades, tendo como menor grão o município e permitindo a construção
de hierarquias, tais como: Unidade da Federação (UF) e Região. A carga nesta
dimensão foi coordednada a partir do arquivo, separado por virgulas,
Municipios_Brasileiros.csv gerado pelo IBGE, segundo a seguinte estrutura:

Fluxo de Execução do job_carga_dm_municipio:

Figura 6: Esquema de Carga do job_carga_dm_municipio

Descrição do Job:

Propriedades Valores
Nome job_carga_dm_municipios
Autor gilmar.correa@consultor.mda.gov.br
Versão 1.0
Propósito Carregar a dimensão municípios
Status Desenvolvimento
Rotina para promover a carga na dm_municipios tendo
Descrição
como origem arquivo (.csv) oriúndo do IBGE.
Criado em 04/07/2018 10:30:10
Modificado em 09/07/2018 16:44:00

Colunas de carga:

Coluna Chave Tipo Nulo

cd_mun_ibge false Integer falso
nm_municipio false String falso
nm_mun_sem_acento false String falso
cd_uf false String falso
sg_uf false String falso
nm_uf false String falso
 Configuração de Colunas no componente tMap do TOS-DI:

3. DM_ENQUADRAMENTO: Entidade de dados do tipo dimensão que

armazena os domínios relativos aos enquadramentos das DAP’s. A carga foi
obtida a partir da tabela dbo.LSTDA_Enquadramento, do SGBD MSSQLServer
e Banco de Dados PRONAF_ESPELHO, conforme:

Fluxo de Execução do job_carga_dm_enquadramento:

Figura 7: job_carga_dm_enquadramento

Descrição do Job:

Propriedades Valores
Nome job_carga_dm_enquadramento
Author gilmar.correa@consultor.mda.gov.br
Versão 1.0
Carregar a entidade de dados do tipo dimensão
Propósito
dm_enquadramento
Status Desenvolvimento
Promover a carga da entidade de dados do tipo dimensão
Descrição
dm_enquadrmaento.
Criado em 11/07/2018 10:13:27
Modificado em 16/07/2018 10:48:20

Configuração de Colunas no componente tMap do TOS-DI:

4. DM_PESSOA_FISICA: Entidade de Dados do tipo Dimensão que

armazena os dados referentes as Pessoas Físicas que tem relacionamento com os
data mart’s do armazém de dados. A carga foi obtida a partir da tabela
dbo.TBPES_FISICA, do SGBD MSSQLServer e Banco de Dados
PRONAF_ESPELHO, conforme:

Fluxo Execução do job_carga_dm_pessoa_fisica:

Figura 9: job_carga_dm_pessoa_fisica
Descrição do Job:

Propriedades Valores
Nome job_carga_dm_pessoa_fisica
Autor gilmar.correa@consultor.mda.gov.br
Versão 1.0
Carregar a dimensão dm_pessoa_fisica a partir dos dados
Propósito
da tabela TBPES_Fisica
Status desenvolvimento
Carregar a dimensão dm_pessoa_fisica a partir dos dados
da tabela TBPES_Fisica do esquena dbo de
Descrição
Pronaf_Espelho a dimens
ao dm_pessoa_fisica do DW NEAD.
Criado em 04/07/2018 15:19:24
Modificado em 09/07/2018 11:06:22

5. DM_PESSOA_JURIDICA: Entidade de Dados do tipo Dimensão que armazena os

dados referentes as Pessoas Jurídicas que tem relacionamento com os data mart’s
do armazém de dados. A carga foi obtida a partir da tabela dbo.TBPES_Juridica, do
SGBD MSSQLServer e Banco de Dados PRONAF_ESPELHO, conforme:

Fluxo de Execução do job_carga_dm_pessoa_juridica:

Figura 8: job_carga_dm_pessoa_juridica
Descrição do Job:

Propriedades Valores
Nome job_carga_dm_pessoa_juridica
Autor gilmar.correa@consultor.mda.gov.br
Versão 1.0
Propósito Carregar a Dimensão dm_pessoa_juridica
Status desenvolvimento
Carregar a Entidade de Dados do Tipo Dimensão
dm_pessoa_juridica com dados oriúndos da entidade de dados
Descrição TBPES_Juridica
depositada no esquema dbo do SGBD MS SQL SERVER e BD
Pronaf_Espelho
Criado em 04/07/2018 14:18:47
Modificado em 05/07/2018 11:09:29
Para a carga das entidade de dados do tipo fato foram utilizadas as rotinas abaixo
especificadas:

1. FT_TITULAR_DAP: Entidade de Dados do tipo Fato que armazena os dados

referentes aos titulares de DAP’s. Decidiu-se definir, pelas características dos dados
de origem, que esses dados deveriam ser acomodados e tratados como eventos, ou
seja, fatos. Devido a quantidade de registros nas entidade de dados de origem e a
complexidades dos lookup’s (união com verificação de consistência entre tabelas),
foi necessário dividir o processo em dois estágios:

1.a) No primeiro estágio as colunas da tabela de origem dbo.TBDA_PesFisica

é consistida com a tabela dbo.TBDAptidao a partir da comparação do CDDA para
obtenção do NumeroDeControleExterno.
Descrição do Job:

Propriedades Valores
Nome job_carga_ft_titular_dap_stg_1
Autor gilmar.correa@consultor.mda.gov.br
Versão 1.0
Propósito Carrega a entidade de dados do tipo fato ft_titular_dap
Status desenvolvimento
Promove a carga na entidade de dados do tipo fato
Descrição ft_titular_dap que armazenas os dados referentes aos
titulares de dap
Criado em 11/07/2018 12:16:31
Modificado em 13/07/2018 14:16:42

2.b) No estágio seguinte o job resgata o arquivo temporário criado no estágio

anterior e completa a execução, por intermédio do lookup com a tabela
dbo.TBPES_Fisica pela consistência do cpf para recuperar dados complementares
do titular, conforme:

Fluxo de Execução do job_carga_ft_titular_dap_stg_2:

 Descrição do JOB:

Propriedades Valores
Nome job_carga_ft_titular_dap_stg_2
Autor gilmar.correa@consultor.mda.gov.br
Versão 1.0
Propósito Carregar a entidade de dados do tipo fato ft_titular_dap
Status desenvolvimento
Promover a carga da entidade de dados do tipo fato
Descrição
ft_titular_dap em seu segundo estágio
Criado em 13/07/2018 13:01:47
Modificado em 13/07/2018 15:02:53

2. FT_SOCIOS_DAP_JURIDICA: Entidade de Dados do tipo Fato que armazena os

dados referentes aos sócios de DAP’s do tipo jurídica, pelas características dos
registros desta tabela de origem optou-se por configura-la como uma fato. A carga
foi obtida a partir da tabela dbo.TBDA_DAPJSocios, do SGBD MSSQLServer e
Banco de Dados PRONAF_ESPELHO, conforme:

Fluxo de Execução do job_carga_ft_socios_dap_juridica:

Figura 11: job_carga_ft_socios_dap_juridica

Descrição do Job:

Propriedades Valores
Nome job_carga_ft_socios_dap_juridica
Autor Gilmar.correa@consultor.mda.gov.br
Versão 1.0
Carregar a entidade de dados do tipo FATO
Propósito
ft_socios_dap_juridica
Status DEV
Promover a carga de dados oriúndas do Pronaf-Espelho na
Descrição
entidade de dados do tipo fato ft_socios_dap_juridica
Criado em 09/07/2018 15:58:03
Modificado em 11/07/2018 10:12:21

3. FT_INSCRICOES_GS: Entidade de Dados do tipo Fato que armazena os dados

referentes as inscrições realizadas no programa Garantia Safra. Decidiu-se definir,
pelas características dos dados de origem, que esses dados deveriam ser
acomodados e tratados como eventos, ou seja, fatos. Devido a quantidade de
registros nas entidade de dados de origem e a complexidades dos lookup’s (união
com verificação de consistência entre tabelas), foi necessário dividir o processo em
dois estágios:

1.a) No primeiro estágio as colunas da tabela de origem

dbo.TBGS_Inscricoes é consistida com a tabela dbo.TBGS_adesoes a partir da
comparação do CD_INSCRICAOGERAL para obtenção de informações
adicionais, conforme abaixo:

Fluxo de Execução do job_carga_ft_inscricoes_gs_stg1:

Figura 12: job_carga_ft_inscricoes_gs_stg_1

 Descrição do Job:

Propriedades Valores
Nome job_carga_ft_inscricoes_gs_stg_1
Autor gilmar.correa@consultor.mda.gov.br
Versão 1.0
Carregar a entidade de dados do tipo fato referente ao
Propósito
contexto Garantia Estágio 1
Status Desenvolvimento
Descrição
Criado em 16/07/2018 13:51:17
Modificado em 16/07/2018 17:23:45

2.b) No estágio seguinte o job resgata o arquivo temporário criado no estágio

anterior e completa a execução, por intermédio do lookup com a tabela
dbo.TBPES_Fisica pela consistência do cpf para recuperar dados complementares
do titular, conforme:

Fluxo de Execução do job_carga_ft_inscricoes_gs_stg_2:

Figura 13: job_carga_inscricoes_gs_stg_2

Descrição do Job:

Propriedades Valores
Nome job_carga_ft_inscricoes_gs_stg_2
Autor gilmar.correa@consultor.mda.gov.br
Versão 0.1
Carregar a entidade de dados do tipo fato referente ao
Propósito
contexto Garantia
Status
Descrição
Criado em 16/07/2018 09:10:43
Modificado em 16/07/2018 17:23:42

4. FT_BENEFICIARIOS_GS: Entidade de Dados do tipo Fato que armazena os

dados referentes aos beneficiários do programa Garantia Safra, pelas características
dos registros desta tabela de origem optou-se por configura-la como uma fato. A
carga foi obtida a partir da tabela dbo.TBGS_Inscricoes onde a coluna
CDStatusDoBeneficiario possui valor igual a 20, do SGBD MSSQLServer e Banco
de Dados PRONAF_ESPELHO, conforme:

Fluxo de Execução do job_carga_ft_beneficiarios_gs:

 Descrição do Job:

Propriedades Valores
Nome job_carga_ft_beneficiarios_gs
Autor gilmar.correa@consultor.mda.gov.br
Versão 1.0
Carregar a entidade de dados do tipo fato
Purpose
ft_beneficiarios_gs referente ao contexto Garantia
Status desenvolvimento
Promover a carga na entidade de dados do tipo fato
Descrição
ft_beneficiarios_gs
Criado em 16/07/2018 12:34:06
Modificado em 16/07/2018 16:07:23
 2.9. CONCEPÇÃO DA CAMADA DE VISUALIZAÇÃO COM A
UTILIZAÇÃO DAS FERRAMENTAS SPAGOBI E DJANGO.

A etapa final do projeto foi a concepção da camada de visualização dos

dados estocados no DDM’s por intermédio da elaboração de Painéis Analíticos com
a finalidade de demonstrar a versatilidade das ferramentas. Porém, para a
construção de painéis fez-se necessária a configuração de acesso, por intermédio
de configuração de fonte de dados (Data Source) JDBC com o SGDB Postgresql,
informando as seguintes rotas de configuração na ferramenta Knowage, como é
conhecida a versão 6.2, de SpagoBI:

Figura 6: Configuração de Fonte de Dados (Data Source) no knowage

Após configurar a fonte de dados faz necessária a configuração da coleção

de dados (Data Set), no caso, configurou-se a coleção de dados sobre a distribuição
quantitativa de DAP’s por Unidade da Federação, conforme abaixo:
 A configuração prossegue ao inserir o tipo de coleção que será armazenada
na ferramenta:

Com a informação de que tipo de coleção será considerada, neste caso,

selecionou-se a opção ‘Query’, consulta.
 Para finalizar, a ferramenta já conectada está pronta para a construção de
painéis analíticos, como a seguir:

O painel acima apresenta os dados relacionados a distribuição quantitativa

de DAP’s Jovens pelas Unidades da Federação e Região do território brasileiro.
 CONCLUSÃO

A construção do Armazém de Dados (DW) e dos Data Marts (DDM’s) que os

compõem que, inicialmente, incorpora os contextos DAP e Garantia Safra, torna
possível a construção de análises de dados integradas. Esse modelo, por ser
evolutivo, vai permitir a incorporação de novos temas e assuntos por intermédio da
construção dos DDM’s. Essa técnica possibilita a integração dos mais diversos
assuntos ampliando sobremaneira as possibilidades de cruzamentos e o
aprimoramento da aplicação de políticas públicas efetivas. O modelo permite o
preciso acompanhamento dos indicadores chave de desempenho (KPI’s) afim de
monitorar a precisão da gestão dos recursos envolvidos. Todo processo de
concepção e construção do projeto teve como premissa a adoção de ferramentas e
soluções de software concebidas sob filosofia de Código Aberto e Software Livre
(FOSS) . Neste produto, em sua primeira fase, já é possível efetivar análises
quantitativas sobre os titulares de DAP’s e suas características particulares, tais
como, quantidade de DAP Mulher, quantidade de DAP Jovem, quantidade de DAP
Jurídica, quantidade de sócios das DAP’s Jurídicas, entre outros cruzamentos como
localização por municipio, unidade da federação, região, ou mesmo, análise
temporal por atributos determinados. O mesmo se aplica aos dados referentes ao
contexto Garantia Safra. Enfim, a contrução deste produto possibilita inúmeras
aplicações e, principalmente, análise em 360° dos dados que possibilita uma gestão
mais qualificada. Outro ponto que merece destaque é o fato de que a arquitetura
utilizada pode ser operada de forma automatizada, utilizando o mínimo de recursos
técnicos e profissionais.
 BIBLIOGRAFIA

Kimball, R. & Ross, M., 2013: Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Difinitive
Guideto Dimensional Modeling, 2013
SÖDERBERG, J, 2008: Johan Söderberg, Hacking Capitalism - The Free and Open Source Software Movement,
2008
NEAD, 2017: NEAD, Termo de Referência CONS NEAD 014/2017, 2017, https://www.iica.org.br
PUC-Rio, 2018: PUC-Rio, Software Livre, 2018,
http://www2.dbd.puc-rio.br/pergamum/tesesabertas/0210500_04_cap_02.pdf
SOMMERVILE, I. 2011: Ian Sommerville, Engenharia de Software, 2011
PRONAF, 2018: MDA, Sobre o Programa, 2018, https://www.bndes.gov.br/wps/portal/site/home/financiamento/
produto/pronaf
SAF, 2018: MDA, Garantia-Safra, 2018, http://www.mda.gov.br/sitemda/secretaria/saf-garantia/sobre-o-
programa
Inmon, W. H., 1999: W. H. Inmon, Die Duden-Rechtschreibprüfung für OOo und LibreOffice, 1999
Kimball, R.; Caserta, J., 2011: Kimball, R.; Caserta, J., The Data Warehouse ETL Toolkit - Practical Techniques
for Extracting, Cleaning, Conforming, and Delivering Data, 2011
Dar, U et all, 2015: Usama Dar, Hannu Krosing, Jim Mlodgenski, Kirk Roybal, PostgreSQL Server
Programming, 2015
Architect, 2018: Best of BI, SQL Power Architect, 2018,