Programa de Pós-graduação em Engenharia de Software
Mestrado Profissional em Engenharia de Software
OpenData Processor: Uma ferramenta para
a automatização do processo de extração e
publicação de Dados Abertos
Allyson Bruno Campos Barros Vilela
Natal / RN Julho de 2018
OpenData Processor: Uma ferramenta para a
automatização do processo de extração e publicação de
Dados Abertos
Dissertação de Mestrado apresentada ao Pro-grama de Pós-graduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Engenharia de Software.
Universidade Federal do Rio Grande do Norte – UFRN
Instituto Metrópole Digital – IMD
Programa de Pós-Graduação em Engenharia de Software
Orientador: Dr. Frederico Araújo da Silva Lopes
Coorientador: Dr. André Gustavo Duarte de Almeida
Natal / RN
Julho de 2018
Vilela, Allyson Bruno Campos Barros.
OpenData Processor: uma ferramenta para a automatização do processo de extração e publicação de Dados Abertos / Allyson Bruno Campos Barros Vilela. - 2018.
97f.: il.
Universidade Federal do Rio Grande do Norte, Instituto Metrópole Digital, Programa de Pós-Graduação em Engenharia de Software, Natal, 2018.
Orientador: Dr. Frederico Araújo da Silva Lopes. Coorientador: Dr. André Gustavo Duarte de Almeida.
1. Dados abertos - Dissertação. 2. Dados abertos governamentais Dissertação. 3. Processo automatizado -Dissertação. 4. SUAP - -Dissertação. 5. CKAN - -Dissertação. I. Lopes, Frederico Araújo da Silva. II. Almeida, André Gustavo Duarte de. III. Título.
RN/UF/BCZM CDU 004 Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
OpenData Processor: Uma ferramenta para a
automatização do processo de extração e publicação de
Dados Abertos
Dissertação de Mestrado apresentada ao Pro-grama de Pós-graduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Engenharia de Software.
Dr. Frederico Araújo da Silva Lopes
Orientador
Dr. André Gustavo Duarte de Almeida
Coorientador
Dr. Gibeon Soares de Aquino Junior
Externo ao Programa
Dr. Francisco Dantas de Medeiros Neto
Externo à Instituição
Natal / RN Julho de 2018
Agradeço primeiramente à Deus pela sua bondade e fidelidade durante esses dois últimos anos. Dia após dia foi possível dizer que até aqui Ele tem me sustentado e que as suas promessas estão sendo cumpridas em minha vida e na vida da minha família.
À meus pais, Marcos e Conceição, pelas orientações e ensinamentos durante os momentos importantes e por sempre terem me apoiado e confiado no meu potencial.
À minha esposa, Railma Almeida, por estar sempre ao meu lado e, com muito amor e compressão, ter me apoiado e me auxiliado a enfrentar e superar todos os desafios que surgiram.
Aos amigos Welkson Medeiros, Renieri Correia, Cesimar Xavier, Tarso Latorraca, Jorge Felliphe e Jackson Meires que estiveram junto comigo nesssa batalha e me ajudaram a chegar até aqui com êxito. E aos demais colegas de turma que contribuíram de alguma forma este trabalho.
Aos professores Frederico e André que foram muito mais do que orientadores. Muito obrigado pelos incentivos, provocações, sugestões e elogios durante essa nossa parceria.
Aos demais professores do PPGSW por terem compartilhado seus conhecimentos e terem contribuído com a minha formação acadêmica e profissional.
Aos demais amigos da AD Semear, da Diretoria de Gestão de Tecnologia da Infor-mação e do Laboratório de Inovação Tecnológica em Saúde que sempre me incentivaram, deram uma palavra de ânimo, que oraram e que desejaram sucesso em todos os momentos de estresse e angústia.
e os seus planos serão bem-sucedidos.” (Bíblia Sagrada, Provérbios 16:3)
O acesso público à informação do governo é um aspecto importante da sociedade moderna que permite a participação ativa da população no monitoramento das ações governamentais. O decreto no 8.777, assinado pela Presidência da República em 11 de maio de 2016, institui
a Política de Dados Abertos do Poder Executivo Federal. A partir dele, os órgãos e entidades da administração pública federal direta, autárquica e fundacional são obrigados a disponibilizarem os dados no formato aberto. No entanto, grande parte dessas instituições estão descumprindo os compromissos definidos no Decreto. Uma possível explicação para esse número é a necessidade dos responsáveis técnicos terem bons conhecimentos de seus sistemas de informação e das legislações vigentes aliada com a dificuldade na extração dos dados visto que na maioria das instituições, todo o processo de extração, publicação e atualização dos dados abertos é feito de forma manual. Nesse sentido, este trabalho propõe o desenvolvimento de uma ferramenta de automatização do processo de extração, publicação e atualização dos dados abertos. Para demonstrar a viabilidade dessa automatização foi utilizado, como estudo de caso, a integração entre o SUAP e o CKAN.
Palavras-chave: dados abertos. dados abertos governamentais. processo automatizado.
Public access to government data is an important aspect of the modern society. It allows the active participation of the population in the monitoration of government actions. Decree No. 8777, signed by the president on May 11, 2016, establishes the Open Data Policy of Brazilian’s Federal Government. According to such decree, the entities of the federal public administration, autarchic and foundational are obliged to make the data available in the open format. However, many of these institutions are re not compliant with the commitments defined in the aforementioned decree. One possible explanation for this is the need for technical staff to have a good knowledge of their information systems and of the current legislation. Moreover, the required tasks to extract and publish data from information systems are, in general, manual. In this sense, this work proposes the a tool to automate the process of extracting, publishing and updating open data. To demonstrate the feasibility of this automation, the integration between SUAP and CKAN was used as a case study.
Figura 1 – Ilustração das 5 estrelas dos dados abertos (5 STAR OPEN DATA, 2017) criado por Tim Berners-Lee em 2010. . . 22 Figura 2 – Diagrama de Arquitetura do SUAP. . . 28 Figura 3 – Abrangência do SUAP. . . 28 Figura 4 – Cenário 1 - Módulo criado dentro do SUAP que permite o gerenciamento,
através da interface web, dos conjuntos de dados que serão publicados no formato aberto por cada um dos setores responsáveis pelos dados. . 42 Figura 5 – Cenário 2 - Aplicação responsável pela extração dos dados através
da API do SUAP, pelo processamento para o formato aberto e pelo carregamento desses dados diretamente no CKAN. . . 43 Figura 6 – Cenário 3 - Junção das vantagens apresentadas no Cenário 1 e Cenário 2. 44 Figura 7 – Parte do formulário de cadastro de um Conjunto de Dados no módulo
de abertura de dados do SUAP. . . 45 Figura 8 – Trecho de código do agendamento da execução do processo de extração
e publicação dos dados para o CKAN. . . 46 Figura 9 – Trecho de código responsável por enviar os arquivos JSON e CSV para
o CKAN. . . 47 Figura 10 – Captura de tela do painel administrativo do OpenData Processor. . . . 52 Figura 11 – Captura de tela da pré-visualização dos dados à serem extraídos. . . . 53 Figura 12 – Captura de tela do preenchimento do dicionário de dados. . . 53 Figura 13 – Captura de tela da configuração do agendamento de extração automática
no OpenData Processor. . . 54 Figura 14 – Captura de tela da funcionalidade de auditoria do OpenData Processor. 54 Figura 15 – Captura de tela de acompanhamento das extrações realizadas pelo
OpenData Processor. . . 55 Figura 16 – Visão geral da arquitetura Standalone disponibilizada em uma máquina
virtual isolada do ambiente do ambiente de produção da Instituição. . . 56 Figura 17 – Visão geral da arquitetura distribuída enfatizando a separação dos
componentes em uma infraestrutura baseada em LXC. . . 57 Figura 18 – Visão geral da arquitetura Multi-inquilino. . . 58 Figura 19 – Visão geral da divisão lógica das instâncias do OpenData Processor no
modelo Multi-inquilino via Banco de Dados. . . 59 Figura 20 – Trecho de código do arquivo docker-compose.yml responsável pelo deploy
dos componentes do OpenData Processor utilizando Docker. . . 60 Figura 21 – Visão geral da arquitetura do OpenData Processor enfatizando a
oferecida pelo OpenData Processor. . . 62
Figura 23 – Trecho de código responsável pela execução da rotina de extração e publicação dos dados no Pentaho Data Integration. . . 66
Figura 24 – Trecho de código responsável pela execução da rotina de extração e publicação dos dados no OpenData Processor. . . 66
Figura 25 – Gráficos comparativos entre o tempo de execução do processo de extra-ção e publicaextra-ção dos dados em cada uma das ferramentas avaliadas. . . 68
Figura 26 – Gráfico comparativo entre o tempo de execução do processo de extração e publicação dos dados em cada uma das ferramentas avaliadas. . . 70
Figura 27 – Gráfico com as respostas para a 1a pergunta do questionário. . . . . 73
Figura 28 – Gráfico com as respostas para a 3a pergunta do questionário. . . . . 74
Figura 29 – Gráfico com as respostas para a 4a pergunta do questionário. . . 75
Figura 30 – Gráfico com as respostas para a 5a pergunta do questionário. . . 75
Figura 31 – Gráfico com as respostas para a 6a pergunta do questionário. . . 76
Figura 32 – Gráfico com as respostas para a 7a pergunta do questionário. . . . . 76
Figura 33 – Gráfico com as respostas para a 1a pergunta do questionário. . . . . 78
Figura 34 – Gráfico com as respostas para a 3a pergunta do questionário. . . . . 79
Figura 35 – Gráfico com as respostas para a 4a pergunta do questionário. . . . . 79
Figura 36 – Gráfico com as respostas para a 5a pergunta do questionário. . . . . 80
Figura 37 – Gráfico com as respostas para a 6a pergunta do questionário. . . . . 80
Tabela 1 – Definição de cada uma das 5 estrelas dos Dados Abertos . . . 22
Tabela 2 – Exemplos de representação dos dados em cada uma das 5 estrelas dos Dados Abertos. . . 24
Tabela 3 – Comparação entre as Plataformas de Dados Abertos . . . 26
Tabela 4 – Avaliação das Ferramentas apresentadas nas seções 3.1, 3.2 e 3.3 . . . 34
Tabela 5 – Requisitos funcionais da ferramenta proposta. . . 39
Tabela 6 – Requisitos não funcionais da ferramenta proposta . . . 40
Tabela 7 – Requisitos de domínio da ferramenta proposta. . . 41
Tabela 8 – Tempo de execução do processo de extração e publicação dos dados para cada um dos cenários. . . 48
Tabela 9 – Comparação entre o consumo de recursos em cada um dos cenários. . . 49
Tabela 10 – Conjuntos de dados selecionados para a realização dos experimentos. . 64
Tabela 11 – Quantidade de memória RAM utilizada durante a execução da extração de cada um dos conjuntos de dados. . . 65
Tabela 12 – Comparativo entre os tempos médios de extração em cada uma das ferramentas. . . 69
Tabela 13 – Respostas para a 2a pergunta do questionário. . . . . 74
Tabela 14 – Respostas para a 8a pergunta do questionário. . . . . 77
Tabela 15 – Respostas para a 9a pergunta do questionário. . . . . 77
Tabela 16 – Respostas para a 2a pergunta do questionário. . . . . 78
Tabela 17 – Respostas para a 8a pergunta do questionário. . . 81
API Application Programming Interface (Interface de Programação de Apli-cativos)
CLI Command Line Interface (Interface de Linha de Comando)
CSV Comma-separated Values (Valores Separados por Vírgula)
ETL Extract, Transform, Load (Extração, Transformação e Carregamento)
GUI Graphical User Interface (Interface Gráfica do Usuário)
HTTP Hypertext Transfer Protocol (Protocolo de Transferência de Hipertexto)
INDA Infraestrutura Nacional de Dados Abertos
IFRN Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Norte
JSON JavaScript Object Notation (Notação de Objetos JavaScript)
LDAP Lightweight Directory Access Protocol (Protocolo de Acesso aos Diretó-rios Leves)
MEC Ministério da Educação
MPDG Ministério do Planejamento, Desenvolvimento e Gestão
ODP OpenData Processor
OKF Open Knowledge Foundation
ONG Organização Não Governamental
PDI Plano de Desenvolvimento Institucional
REST Representational State Transfer (Transferência de Estado Representaci-onal)
SETEC Secretaria de Educação Profissional e Tecnológica
SAAS Software as a Service (Software como Serviço)
SIG Sistema de Informações Gerencial
TCU Tribunal de Contas da União
TI Tecnologia da Informação
TSV Tab-separated Values (Valores Separados por Tabulação)
XML-RPC Protocolo de chamada de procedimento remoto que utiliza XML para codificar suas chamadas e HTTP como um mecanismo de transporte
1 INTRODUÇÃO . . . 16 1.1 Problemática e Motivação . . . 17 1.2 Objetivos . . . 18 1.2.1 Objetivos Específicos . . . 18 1.3 Metodologia . . . 19 2 REFERENCIAL TEÓRICO . . . 20 2.1 Dados Abertos . . . 20
2.2 Dados Conectados e Dados Abertos Conectados . . . 21
2.3 Plataformas de Dados Abertos . . . 25
2.4 Sistema Unificado de Administração Pública (SUAP). . . 27
3 TRABALHOS RELACIONADOS . . . 29
3.1 Extração, Transformação e Publicação (ETL) de Dados Abertos . . 29
3.2 Extração e Transformação de Dados. . . 30
3.3 Publicação dos Dados nas Plataformas de Dados Abertos . . . 31
3.4 Comparativo entre as Ferramentas. . . 32
3.4.1 Funcionalidades Desejadas . . . 32
3.4.1.1 Configuração (CO) . . . 32
3.4.1.2 Extração (E) . . . 32
3.4.1.3 Transformação (T) . . . 32
3.4.1.4 Descrição dos Dados (DD) . . . 33
3.4.1.5 Carregamento (CA) . . . 33
3.4.1.6 Agendamento de Tarefas (A) . . . 33
3.4.1.7 Registro de Execução de Tarefas (L) . . . 33
3.4.1.8 Notificação (N) . . . 33
3.4.2 Avaliação das Ferramentas . . . 33
3.4.3 Discussão dos Resultados . . . 36
4 PROPOSTA DE AUTOMATIZAÇÃO DO PROCESSO DE EXTRA-ÇÃO, PUBLICAÇÃO E ATUALIZAÇÃO DE DADOS ABERTOS . . 38
4.1 Requisitos Funcionais . . . 38
4.2 Requisitos Não Funcionais . . . 39
4.3 Requisitos de Domínio . . . 40
4.4 Implementação da Proposta de Automatização do Processo de Ex-tração, Publicação e Atualização de Dados Abertos . . . 41
4.4.1.1 1 Cenário . . . 42
4.4.1.2 2o Cenário . . . 43
4.4.1.3 3o Cenário . . . 43
4.4.2 Implementação dos Cenários . . . 44
4.4.2.1 Cenário 1 . . . 44
4.4.2.2 Cenário 2 . . . 45
4.4.2.3 Cenário 3 . . . 46
4.4.3 Avaliação dos cenários . . . 47
4.4.3.1 Avaliação de Desempenho . . . 47
4.4.3.2 Discussão dos Resultados da Avaliação Quantitativa . . . 49
4.5 Conclusões . . . 50
5 OPENDATA PROCESSOR: UMA FERRAMENTA PARA A AUTO-MATIZAÇÃO DO PROCESSO DE EXTRAÇÃO, PUBLICAÇÃO E ATUALIZAÇÃO DE DADOS ABERTOS . . . 51
5.1 Funcionalidades do OpenData Processor . . . 51
5.2 Arquitetura da Aplicação . . . 55
5.2.1 Standalone . . . 56
5.2.2 Distribuída . . . 57
5.2.3 Multi-inquilino ou Software como Serviço (SaaS) . . . 57
5.3 Deploy . . . 59
6 COMPARAÇÃO ENTRE O OPENDATA PROCESSOR E AS FER-RAMENTAS EXISTENTES . . . 63
6.1 Avaliação de desempenho durante a extração de grandes volumes de dados . . . 63
6.1.1 Análise dos Resultados . . . 64
6.2 Comparação do tempo de execução da extração e publicação dos dados abertos entre o Pentaho Data Integration e o OpenData Processor . . . 66
6.2.1 Análise dos Resultados . . . 67
6.3 Comparação da utilização do OpenData Processor e do Pentaho Data Integration para a automatização do processo de extração e publicação dos dados abertos . . . 70
6.3.1 Questionários Aplicados Durante o Experimento . . . 71
6.3.2 Análise dos Resultados . . . 73
6.3.2.1 Respostas obtidas durante a avaliação do uso do Pentaho Data Integration para a automatização da extração e publicação de dados abertos. . . 73
automatização da extração e publicação de dados abertos . . . 77
6.3.2.3 Discussão dos Resultados obtidos durante o experimento . . . 82
7 CONCLUSÕES . . . 83
7.1 Trabalhos Futuros . . . 83
REFERÊNCIAS . . . 85
APÊNDICES
89
APÊNDICE A – ROTEIRO DE TAREFAS DO EXPERIMENTO 3 - PENTAHO DATA INTEGRATION . . . 90APÊNDICE B – ROTEIRO DE TAREFAS DO EXPERIMENTO 3 - OPENDATA PROCESSOR . . . 94
1 Introdução
O acesso à informação é um importante aspecto da sociedade moderna uma vez que permite a participação ativa da população na fiscalização das ações governamentais e contribui com a melhoria da gestão pública e do combate à corrupção (TRIBUNAL DE CONTAS DA UNIÃO, 2016). Para o Tribunal de Contas da União (TCU), a abertura dos dados na Administração Pública contribui para uma melhor transparência na gestão pública a partir da contribuição da sociedade através da criação de soluções inovadoras para fiscalização desses dados (TRIBUNAL DE CONTAS DA UNIÃO,2016). Nesse sentido, o Decreto no 8777 (BRASIL, 2016), assinado pela Presidência da República em 11 de Maio de 2016, instituiu a Política de Dados Abertos do Poder Executivo Federal.
De acordo com o Open Knowledge International (OPEN KNOWLEDGE INTER-NATIONAL, 2017d), uma organização global sem fins lucrativos focada em difundir a importância do acesso e uso dos dados abertos na sociedade civil, “dados são abertos quando qualquer pessoa pode livremente acessá-los, utilizá-los, modificá-los e compartilhá-los para qualquer finalidade, estando sujeito, no máximo, a exigências que visem preservar sua proveniência e sua abertura” (OPEN KNOWLEDGE INTERNATIONAL,2016 apud TRIBUNAL DE CONTAS DA UNIÃO, 2016). Seguindo essa linha, dados abertos go-vernamentais são aqueles gerados pelo governo e colocados à disposição da sociedade, objetivando não apenas sua leitura, como também o seu acompanhamento, reutilização em sites e aplicações externas e o cruzamento com outros dados de órgãos/esferas diferentes (NÚCLEO DE INFORMAÇÃO E COORDENAÇÃO DO PONTO BR, 2011). Diante disso, os órgãos e entidades da administração pública federal direta, autárquica e funda-cional são obrigados a publicarem os seus dados de forma aberta, segundo as diretrizes definidas na Infraestrutura Nacional de Dados Abertos (INDA) do Ministério do Plane-jamento, Desenvolvimento e Gestão (MPDG) (MINISTÉRIO DO PLANEJAMENTO, DESENVOLVIMENTO E GESTÃO,2017).
Dentre os órgãos obrigados à publicarem seus dados no formato abertos estão os Institutos Federais de Ensino que compõe a Rede Federal de Educação Profissional, Científica e Tecnológica, vinculada ao Ministério da Educação. Fazem parte dessa rede: Institutos Federais de Educação, Ciência e Tecnologia, Centros Federais de Educação Tec-nológica, Escolas Técnicas Vinculadas às Universidades Federais, Universidade Tecnológica Federal do Paraná e o Colégio Pedro II (Rede Federal de Educação Profissional, Científica e Tecnológica, 2017). Dessa forma, cada uma dessas instituições necessitam disponibilizar um portal para divulgação dos seus dados abertos, realizar a extração periódica dos dados em seus sistemas de informação e a publicação/atualização desses dados em seu portal de dados abertos.
De um modo geral, todo o processo de extração e publicação dos dados é feito de forma manual por uma pessoa da equipe de desenvolvimento, que possui a expertise necessária da organização dos bancos de dados, nas legislações e recomendações vigentes para a publicação de dados abertos no âmbito do Governo Federal Brasileiro. A literatura apresenta algumas ferramentas que possibilitam uma certa automatização do processo de publicação de dados abertos, como por exemplo: WPRDC-ETL (WESTERN PENNSYL-VANIA REGIONAL DATACENTER, 2017), CKAN Automator (OPEN NORTH, 2017), UnifiedViews (KNAP et al., 2014), OpenDataNode (COMSODE,2017) e Pentaho Data Integration (PENTAHO, 2017b). No entanto, tais ferramentas exigem uma árdua inter-venção da equipe de TI para implementar, configurar ou executar todos os procedimentos necessários para tal processo. Dessa forma, o objetivo deste trabalho é desenvolver uma ferramenta que possibilite a automatização do processo de extração e publicação de dados abertos.
1.1
Problemática e Motivação
O Decreto no 8.777, assinado pela Presidência da República em 11 de Maio de
2016, instituiu a Política de Dados Abertos do Poder Executivo Federal. A partir dele, os órgãos e entidades da administração pública federal direta, autárquica e fundacional são obrigados a disponibilizarem os dados, que não estejam sob sigilo ou sob restrição de acesso, contidos em seus banco de dados sob a forma de dados abertos. Isso possibilita um aprimoramento da cultura de transparência pública para a sociedade e facilitar a troca de informações entre órgãos e entidades da administração pública federal e as diferentes esferas da federação (BRASIL, 2016).
No entanto, apesar dessa obrigação, apenas 85 das 210 instituições estão cumprindo os compromissos definidos no Decreto 8.777/2016 (MINISTÉRIO DO PLANEJAMENTO, DESENVOLVIMENTO E GESTÃO, 2017). Por exemplo, os Institutos Federais de Edu-cação, Ciência e Tecnologia de todo o país são obrigados a publicarem os seus dados de forma aberta, segundo as diretrizes definidas na Infraestrutura Nacional de Dados Abertos (INDA) do Ministério do Planejamento, Desenvolvimento e Gestão (MPDG). Entretanto, de acordo com o Painel de Monitoramento dos Dados Abertos 1 da CGU
(CONTROLADORIA-GERAL DA UNIÃO, 2018), até o momento, apenas 5 dos 38 Insti-tutos Federais de Ensino estão publicando seus dados no formato aberto, ou seja, grande parte dos Institutos estão descumprindo o Decreto no 8.777.
Tomando como exemplo o caso do Instituto Federal de Educação, Ciência e Tecnolo-gia do Rio Grande do Norte (IFRN), todo o processo de extração, publicação e atualização dos dados vem sendo feito de forma manual por um dos analistas de TI do instituto.
Ou seja, a inexistência de uma integração entre o sistema de informação utilizado no instituto e a plataforma de dados abertos torna todo o processo de extração, publicação e atualização dos dados complexo e demorado. Além disso, outros 27 Institutos Federais utilizam o mesmo sistema e, dessa forma, a automatização desse processo possibilitará uma maior facilidade e agilidade na publicação dos dados abertos dos institutos.
Essa dificuldade na execução do processo de extração, publicação e atualização dos dados devido à falta de integração entre os sistemas de informação e as plataformas de dados abertos também deve estar presente em outros órgãos e entidades da administração pública federal direta, autárquica e fundacional, o que justificaria o baixo número de instituições que estão cumprindo o Decreto no 8.777. Ou seja, além de todo esse processo ser feito de forma manual, é exigido que a equipe responsável pela abertura dos dados nas instituições possuam bons conhecimentos de seus sistemas de informação e das legislações vigentes.
Nesse sentido, a automatização do processo de extração, publicação e atualização de dados abertos possibilitará que as instituições públicas da administração pública federal direta, autárquica e fundacional publiquem seus dados com uma maior facilidade e agilidade, passando a cumprir integralmente o Decreto no 8.777.
1.2
Objetivos
Este trabalho tem por objetivo geral a facilitação e a agilização da abertura de dados nas instituições públicas através da automatização do processo de extração, publicação e atualização dos dados abertos.
1.2.1
Objetivos Específicos
Os objetivos específicos deste trabalho são:
1. Identificar as formas possíveis para a integração entre os sistemas de informação já existentes e as plataformas de dados abertos;
2. Desenvolver uma ferramenta que automatize o processo de extração, publicação e atualização dos dados abertos;
3. Realizar a validação da ferramenta desenvolvida;
4. Realizar a avaliação e comparação entre a ferramenta desenvolvida e as ferramentas já existentes no mercado;
1.3
Metodologia
Inicialmente, realizamos uma da revisão bibliográfica focada em artigos que tratam sobre interoperabilidade entre sistemas de informação já existentes e as plataformas de dados abertos. A partir dela foi possível identificar as formas possíveis para a extração de dados de sistemas de informação já existentes. Com isso, as formas de extração identificadas foram: através de arquivos de planilha eletrônica (XLS, XLSX ou CSV), diretamente do banco de dados ou a partir de serviços web (REST ou SOAP).
A revisão bibliográfica em artigos e a leitura das recomendações elaboradas por entidades dos EUA (OPEN KNOWLEDGE INTERNATIONAL,2017a;CODE FOR AME-RICA, 2017), Nova Zelândia (CODE FOR AOTEAROA, 2017), Austrália (AUSTRÁLIA, 2017) e do Canadá (CANADÁ,2017) para a publicação de dados abertos possibilitaram a identificação de ferramentas gratuitas e pagas que permitem uma certa automatização no processo de extração e publicação dos dados abertos.
Para a realização da validação da automatização do processo de extração, publicação e atualização dos dados abertos foi realizado um estudo de caso utilizando o SUAP, que é desenvolvido pelo IFRN e que é utilizado por outras 30 instituições públicas espalhadas pelo Brasil e o CKAN, plataforma de dados abertos recomendada pela INDA. Inicialmente no estudo de caso foram desenvolvidos três cenários arquiteturais, apresentados na seção 4.4.1, para validar se a integração entre o SUAP e o CKAN seria possível e, também, realizar a avaliação das vantagens e desvantagens da realização da extração dos dados através do banco de dados e através de serviços web.
Para a realização da avaliação e comparação entre a ferramenta desenvolvida e as ferramentas já existentes no mercado, foram realizados três experimentos que objetivaram avaliar a capacidade máxima de extração da ferramenta desenvolvida, comparar o tempo de extração e a facilidade de utilização entre as ferramentas já existentes e a ferramenta desenvolvida.
2 Referencial Teórico
Este capítulo apresenta os principais aspectos teóricos relacionados ao trabalho, dessa forma as Seções2.1 e 2.2 abordam os conceitos relacionados à dados abertos, dados abertos governamentais e dados abertos conectados. A Seção 2.3 apresenta as plataformas existentes para a publicação de dados abertos. E a Seção 2.4 apresenta Sistema Unificado de Administração Pública (SUAP) que foi utilizado como estudo de caso no Capítulo 4.
2.1
Dados Abertos
O Laboratório Brasileiro de Cultura Digital e o Núcleo de Informação e Coordenação do Ponto BR (NÚCLEO DE INFORMAÇÃO E COORDENAÇÃO DO PONTO BR, 2011) definem dados abertos como: “Para ser considerado aberto, todo dado público deve ser completo, primário (sem tratamento), atual, compreensível por máquina, não discriminatório, acessível, não proprietário e com licenças que garantam esses princípios e não cerceiem a liberdade de uso”. Seguindo essa definição, a Open Government Data define como dados abertos governamentais os dados disponibilizados em formato aberto que foram produzidos, coletados e armazenados por governos ou entidades governamentais. A abertura dos dados governamentais proporciona resultados positivos na transparência e controle democrático, na participação popular, na melhoria e desenvolvimento de novos produtos e serviços, na inovação e na eficiência governamental (OPEN GOVERNMENT DATA, 2017). Entretanto, para obter os resultados esperados, é necessário que os dados sigam as três leis dos dados abertos (EAVES,2009) e os oito princípios dos dados governamentais (TAUBERER, 2014):
As três leis dos dados abertos são:
1. Os dados precisam ser encontrados e indexados na web;
2. Os dados devem estar em um formato aberto e devem ser compreensíveis por máquina;
3. Os dados não devem ter restrições quanto à sua utilização.
Já os oito princípios dos dados governamentais são:
1. Completos: Todos os dados públicos, ou seja, que não possuem restrição de acesso, licença ou privacidade deverão ser disponibilizados;
2. Primários: Os dados devem ser disponibilizados da mesma forma na qual foram cole-tados, com o maior nível de granularidade possível, sem modificações ou agregações;
3. Atuais: Os dados devem ser disponibilizados o mais rápido possível;
4. Acessíveis: Os dados devem ser disponibilizados para o maior número possível de usuários e de possibilidades de utilização;
5. Compreensíveis por máquinas: Os dados devem estar estruturados de modo que seja possível processá-los de forma automatizada;
6. Não discriminatórios: Os dados devem ser disponibilizados para todos, sem a exigência de cadastro ou requisição de acesso;
7. Não proprietários: Os dados devem estar em formato livre como JSON, XML ou CSV ;
8. Livres de licenças: Os dados não devem estar submetidos à nenhum tipo de licença de uso, direito autoral, patente, propriedade intelectual ou segredo industrial. Porém, são permitidas restrições relacionadas à privacidade, segurança e privilégios de acesso.
No Brasil, as iniciativas para a abertura de dados governamentais começaram a surgir após a integração da Parceria para Governo Aberto (Open Government Partnership – OGP), que trata-se de uma iniciativa internacional que visa difundir e incentivar ações e práticas governamentais que contribuam com a melhoria na transparência dos governos, acesso à informação pública e a participação social (CONTROLADORIA-GERAL DA UNIÃO,2017). No restante do mundo, o projeto Open Data Barometer (WORLD WIDE WEB FOUNDATION, 2016) realizou um estudo sobre as iniciativas de dados abertos durante os anos de 2013, 2014 e 2015. Nas três edições do estudo, o Reino Unido foi classificado como o país mais avançado na abertura de dados governamentais enquanto que o Brasil ocupou, respectivamente, a 28a, 21a e 17a posição do ranking. (WORLD WIDE
WEB FOUNDATION, 2016).
2.2
Dados Conectados e Dados Abertos Conectados
Dados conectados, do inglês Linked Data, é um conceito que foi introduzido pelo Sir Timothy John Berners-Lee, inventor da World Wide Web (WWW), no ano de 2006 e pode ser definido como um conjunto de boas práticas para publicar e conectar conjuntos de dados estruturados na Web (BIZER; HEATH; BERNERS-LEE, 2009 apud ISOTANI; BITTENCOURT, 2015).
Os dados conectados permitem que os dados publicados por qualquer pessoa possam ser lidos por outras pessoas e processados por máquinas, contribuindo com a integração semântica dos dados e estimulando o desenvolvimento de novos tipos de aplicações e ferramentas (ISOTANI; BITTENCOURT, 2015).
Figura 1 – Ilustração das 5 estrelas dos dados abertos (5 STAR OPEN DATA,2017) criado por Tim Berners-Lee em 2010.
Fonte: (5 STAR OPEN DATA,2017)
Para classificar o grau de abertura e conexão dos dados, Tim Berners-Lee propôs 5 princípios conhecidos como “Sistema de 5 estrelas”, o qual é ilustrado na Figura 1. Nele, quanto maior o número de estrelas, maior será o grau de abertura e conexão dos dados. Segundo a W3C Brasil (W3C BRASIL, 2013 apudISOTANI; BITTENCOURT, 2015), é aconselhável que os dados sejam abertos com no mínimo 3 estrelas, porém para ser considerado como dado conectado é necessário no mínimo 4 estrelas.
A Tabela 1 define cada uma das 5 estrelas dos Dados Abertos (5 STAR OPEN DATA, 2017):
Tabela 1 – Definição de cada uma das 5 estrelas dos Dados Abertos
No de Estrelas Descrição
9 Disponível na Internet, em qualquer formato, desde que com licença aberta.
99 Disponível na Internet de maneira estruturada . 999 Disponível na Internet de maneira estruturada e em formato não
proprietário.
9999 Mesmas regras anteriores além da utilização de URIs para identificar os recursos na web.
99999 Mesmas regras anteriores além da conexão com outros dados com o intuito de fornecer um contexto para os dados.
A Tabela 2 exemplifica a representação dos dados em cada uma das 5 estrelas através da utilização do cenário proposto em 5 STAR OPEN DATA (5 STAR OPEN DATA, 2017), onde foi disponibilizado a previsão de temperatura dos próximos 3 dias de Galway, uma cidade da Irlanda (ISOTANI; BITTENCOURT, 2015).
Tabela 2 – Exemplos de representação dos dados em cada uma das 5 estrelas dos Dados Abertos.
No de Estrelas Exemplo de Representação Comentários 9 Os dados estão contidos em
um documento PDF disponibi-lizado na web através do en-dereço http://5stardata.info/pt-BR/examples/gtd-1.pdf.
Apesar de estar disponível na web, os dados não são facilmente inter-pretados por máquina.
99 Os dados estão estruturados em uma planilha do Excel no formato XLS disponibili-zada na web através do ende-reço http://5stardata.info/pt-BR/examples/gtd-2.xls.
Embora seja um pouco mais fácil do que o exemplo anterior, para ser processado por máquina é ne-cessário utilizar um software pro-prietário.
999 Os dados estão estruturados em um arquivo CSV disponibi-lizado na web através do en-dereço http://5stardata.info/pt-BR/examples/gtd-3.csv.
Agora os dados podem ser proces-sados livremente, sem a necessi-dade de nenhum software especí-fico, por máquina. Entretanto, não é possível representar esses dados com uma riqueza maior de deta-lhes.
9999 Os dados estão estruturados em um documento no formato RDF (Resource Description Framework) através do ende-reço http://5stardata.info/pt-BR/examples/gtd-4/.
O RDF é um formato utilizado para representar informações na web que permite que os dados se-jam disponibilizados em diferen-tes formas como JSON e HTML permitindo assim que os dados sejam consumidos tanto por pes-soas quanto por máquinas de uma forma simplificada.
99999 Os dados estão estruturados da mesma maneira que no exemplo anterior através do en-dereço http://5stardata.info/pt-BR/examples/gtd-5/ e estão co-nectados com dados de outras fon-tes.
A partir dessa conexão com da-dos de outras fontes é possível, por exemplo, apresentar informa-ções adicionais sobre a cidade de Galway.
Fonte: Elaborada pelo autor.
Nesse sentido, ao atingir as 5 estrelas os dados são considerados Dados Abertos Conectados.
2.3
Plataformas de Dados Abertos
Após o processo de definição de quais dados serão abertos, é necessário realizar a publicação dos mesmos na web para uso irrestrito da sociedade. Os dados abertos podem ser disponibilizados em páginas na web, através de um website com uma interface de busca, ou podem ser expostos através de uma API (Application Programming Interface) pública, permitindo que sistemas de informação consumam os dados de forma automatizada (NÚCLEO DE INFORMAÇÃO E COORDENAÇÃO DO PONTO BR, 2011). Tal
auto-matização visa facilitar o processo de busca dos dados abertos, sendo utilizados catálogos ou plataformas de dados abertos, que podem ser definidos como um software ou serviço que faz a gestão e publicação na web destes dados e seus metadados. Estas plataformas permitem a busca, inclusão, alteração e exclusão desses metadados (MIRANDA,2013).
A plataforma para gestão e publicação de dados abertos mais utilizada no mundo é o CKAN (OPEN KNOWLEDGE INTERNATIONAL,2017b). De código livre e desenvolvida em Python, mantida pela Open Knowledge International, dentre as funcionalidades do CKAN estão: a possibilidade de visualização dos dados catalogados, o controle de acesso à conjuntos de dados não públicos, hospedagem e transformação de arquivos, APIs para integração ou consumo dos dados de forma automatizada e a colheita automática de dados. O CKAN é utilizado por governos, prefeituras e organizações públicas de diversos países como o Brasil, Uruguai, Canadá, Reino Unido, Estados Unidos, Irlanda, Romênia, Austrália, Holanda, Itália, Argentina e Alemanha (OPEN KNOWLEDGE INTERNATIONAL, 2017b).
Semelhantemente, o DKAN (GRANICUS,2017) também é de código-aberto e é desenvolvido e mantido pela Granicus. Baseado no Drupal, sistema gerenciador de conteúdo escrito em PHP, o DKAN permitre ainda a catalogação, publicação e visualização dos dados abertos, é possível utilizar um módulo opcional que otimiza o fluxo de trabalho da equipe responsável pela gestão dos dados através da revisão dos dados cadastrados. O DKAN também permite a criação de dashboards e outras ferramentas de visualização dos dados, a fácil customização da interface do portal e a integração com outros softwares. A plataforma é utilizada em mais de 100 portais de dados abertos, e em mais de 30 países e 35 cidades.
Outra plataforma para gestão e publicação de dados abertos é a Junar Open Data Platform (JUNAR, 2017). A plataforma é uma solução proprietária, que roda em ambiente de nuvem como um serviço (SaaS) e desenvolvida em Python. Seu principal objetivo é ajudar governos, empresas, ONGs, universidades e laboratórios de pesquisa no processo de publicação de seus dados abertos de forma simples, rápida, personalizada, segura e controlada. O Junar permite a coleta, melhoria, publicação, compartilhamento e análise, através de tabela, gráficos ou mapas, dos dados abertos de forma que usuários comuns, em qualquer dispositivo, possam compreender do que se trata e qual o valor de cada dado
publicado. A plataforma é utilizada por organizações dos Estados Unidos, Costa Rica, Argentina e Chile (JUNAR, 2017).
O Socrata (SOCRATA, 2017b) é mais uma alternativa para a gestão dos dados abertos. Assim com o Junar, ele também é uma solução proprietária que roda em ambiente de nuvem como um SaaS. A plataforma permite a publicação de centenas de milhares de dados nos mais variados tipos como dados geoespaciais, financeiros, de segurança pública e através de uma interface de busca otimizada permite que os usuários e motores de buscas, de forma fácil e rápida, encontrem os catálogos de dados publicados (SOCRATA, 2017b). Para Miranda (MIRANDA, 2013;OLIVEIRA L.; LÓSCIO, 2014), o principal diferencial do Socrata é a criação de visualizações mais elaboradas, o qual permite a criação de gráficos, mapas e formatação condicional. Não foi possível identificar em qual tecnologia essa ferramenta foi desenvolvida.
O OpenDataSoft (OPENDATASOFT,2017) é uma solução proprietária, baseada em nuvem computacional e na tecnologia Python, que permite a gestão dos dados abertos. Tal ferramenta foi desenvolvida visando facilitar a gestão dos dados. Através de uma interface intuitiva é possível publicar os catálogos de dados com poucos cliques. Ele também permite a visualização dos dados a partir de quadros, gráficos, mapas e imagens, também é possível compartilhar os dados em outros formatos. A ferramenta gera automaticamente APIs para consumo dos dados por aplicações desenvolvidas por terceiros e permite o monitoramento da utilização dos dados através de um painel administrativo. A plataforma é utilizada por prefeituras e instituições da administração pública de países europeus e dos Estados Unidos (OPENDATASOFT,2017).
Tabela 3 – Comparação entre as Plataformas de Dados Abertos
Descrição CKAN DKAN Junar Socrata OpenDataSoft
Gratuita e de Código Aberto Sim Sim Não Não Não API para leitura de dados Sim Sim Sim Sim Sim API para cadastro de dados Sim Sim Não Sim Não
Interface Customizável Sim Sim Sim Sim Sim
Extensível Sim Sim Sim Não Sim
Desenvolvida em Python PHP Python ? Python
Fonte: Elaborada pelo autor.
A Tabela 3 mostra uma comparação entre as funcionalidades de cada uma das plataformas citadas acima. No IFRN, optou-se por utilizar o CKAN pelo fato da plata-forma ser de código aberto, desenvolvida na linguagem Python, o que facilita eventuais customizações pelo já que a equipe de desenvolvimento utiliza essa linguagem em seu dia a dia, e por ele ser utilizado no Portal Brasileiro de Dados Abertos (BRASIL, 2017) e por outros órgãos da Administração Pública Federal.
2.4
Sistema Unificado de Administração Pública (SUAP)
O SUAP é um sistema corporativo web desenvolvido pela Diretoria de Gestão e Tecnologia da Informação do IFRN. Seu desenvolvimento, que iniciou no ano de 2007, visa o atendimento das ações desenvolvidas pela Reitoria, Pró-Reitorias, Diretorias Sistêmicas e Direções-Gerais dos Campi e desde então vem sendo constantemente aperfeiçoado.
Abrangendo todas as oito dimensões sistêmicas, definidas no âmbito do Plano de Desenvolvimento Institucional (PDI) do Instituto Federal (Administração, Assistência Estudantil, Ensino, Extensão, Gestão de Pessoas, Pesquisa, Planejamento e Tecnologia da Informação), o SUAP possui, somente no IFRN, cerca de 35 mil usuários e conta com mais de 40 módulos que gerenciam os processos de Gestão de Pessoas, Gestão Acadêmica, Controle Patrimonial, Gerenciamento de Almoxarifado, Ponto Eletrônico, Planejamento Anual, Gestão de Projetos de Extensão, Gestão de Protocolo de Documentos, Controle de Acesso a chaves de ambientes, Frota de Veículos, Gestão de Contratos e Convênios, Gestão Orçamentária, Catálogo de Materiais.
O SUAP é desenvolvido utilizando tecnologias de software livre. Dentre as tecno-logias utilizados estão a linguagem de programação Python, o Django (framework para desenvolvimento de aplicações web), o PostgreSQL como SGBD e o NGINX e Gunicorn, respectivamente, como servidor HTTP e de aplicação. A principal forma de acesso ao SUAP é através da interface web ou do aplicativo móvel. Estes dois clientes se comunicam através de requisições HTTP enviadas para o servidor web Nginx que responde pelo domí-nio suap.ifrn.edu.br. O Nginx é responsável por tratar essas requisições e redirecioná-las, através de proxy reverso, para o servidor de aplicação Gunicorn ou servir diretamente os arquivos de mídia estáticas (Javascript, CSS, PNG e etc). O Gunicorn é responsável por executar uma ou mais instâncias da aplicação Django e a partir dessas instâncias são feitos os acessos ao banco de dados, ao servidor de LDAP utilizado para a gestão da identidade dos usuários e ao sistema de arquivos do SO. Existem outros três tipos de clientes escritos em Java que se comunicam diretamente com o servidor de aplicação do SUAP através de um webservice XML-RPC. A Figura 2 ilustra a arquitetura do SUAP.
Após a expansão da Rede Federal de Educação, a Secretaria de Educação Profissio-nal e Tecnológica (SETEC) do Ministério da Educação (MEC) negociou com o IFRN a possibilidade de disponibilizar, em caráter experimental, o sistema para os demais Institu-tos Federais com o objetivo de, no futuro, transformá-lo em Sistema de Administração padrão para a Rede Federal. Nessa direção, atualmente 30 instituições, sendo 27 destas Institutos Federais, já assinaram o termo de cooperação com o IFRN e estão em processo de implantação ou já estão utilizando o SUAP. A Figura 3ilustra a abrangência do SUAP.
Figura 2 – Diagrama de Arquitetura do SUAP.
Fonte: Elaborada pelo autor.
Figura 3 – Abrangência do SUAP.
3 Trabalhos Relacionados
Este capítulo faz uma categorização, apresentando os detalhes de cada um dos trabalhos relacionados e, por fim, é feita uma comparação dos trabalhos relacionados com a ferramenta desenvolvida durante a pesquisa.
3.1
Extração, Transformação e Publicação (ETL) de Dados
Aber-tos
DataGraft - Simplifying Open Data Publishing (ROMAN et al., 2016): O artigo apresenta uma plataforma de código aberto que fornece recursos de transformação, publicação e hospedagem de dados visando simplificar o ciclo de vida da publicação de dados para a equipe responsável pela publicação dos dados. A plataforma provê um framework de limpeza e tratamento de dados que fornece feedback imediato aos técnicos responsáveis sobre como as mudanças de dados aceleram o processo de transformação e melhoram a qualidade do resultado. Os dados tratados são publicados na própria plataforma, dessa forma não é preciso utilizar uma instância do CKAN ou outra plataforma para publicação de dados abertos.
Open Data Node (COMSODE, 2017): Plataforma de código aberto que provê mecanismos automatizados para a publicação de dados abertos e dados abertos conectados de forma simples. A plataforma dá suporte à todo o processo de publicação dos dados abertos através da capacidade de ETL, através de plugins do UnifiedViews, tanto para dados conectados quanto para dados tabulares ou relacionais, que permitem converter, limpar, enriquecer e conectar os dados. Além disso, o Open Data Node possui integração com o CKAN e o Socrata, permitindo a publicação automática dos dados nessas duas plataformas.
WPRDC-ETL (WESTERN PENNSYLVANIA REGIONAL DATACENTER,
2017): Biblioteca desenvolvida em Python pelo Centro de Dados Regional do Oeste da Pensilvânia para a automatização do processo de publicação de dados abertos através de processos de ETL que fazem a extração dos dados brutos, os transforma para um formato útil e os carrega em seu portal de dados abertos que utiliza o CKAN.
Open Data ETL Toolkit (CITY OF CHICAGO,2017): Conjunto de ferramentas que auxiliam os governos na automatização do processo de ETL através do uso do Kettle (PENTAHO, 2017a). Com ele é possível extrair os dados a partir de um banco de dados (MySQL, PostgreSQL, Oracle, SQL Server além de bancos de dados NoSQL), API ou arquivos de texto e carregá-los diretamente no Socrata. As ferramentas são compatíveis
com sistemas operacionais Windows e Linux.
3.2
Extração e Transformação de Dados
A Content-Driven ETL Processes for Open Data (BERRO; MEGDICHE;
TESTE, 2015): No artigo é apresentado um processo de ETL orientado à conteúdo que automatiza a fase de extração baseada apenas no conteúdo das fontes de dados. No processo são utilizados mecanismos de anotação e mineração de dados para descobrir relações hierárquicas entre os dados. Uma vez processados, os dados são transformados em diagramas de esquema de instância que os tornam exploráveis em sistemas de suporte à decisão, bem como extensíveis para a web semântica. No artigo também são propostos algoritmos genéricos que são capazes de extrair, enriquecer e transformar estruturas em dados abertos, independentemente da complexidade das fontes.
Pentaho Data Integration - Kettle (PENTAHO, 2017a): Solução de código aberto que permite a extração e transformação de dados. Ela permite que os usuários possam combinar, preparar ou limpar dados oriundos de diversas fontes através de ferramentas visuais, do tipo drag-and-drop, que eliminam a complexidade e a necessidade de codificação. O Kettle também permite a integração com ferramentas de terceiros ou outras plataformas do Pentaho (PENTAHO, 2017b).
UnifiedViews (KNAP et al., 2014): No artigo é apresentado um framework de código aberto voltado para a extração, transformação e carregamento de dados. Ele permite que os usuários, responsáveis pela publicação, consumo ou análise dos dados, possam, através de sua interface gráfica, administrar, depurar e monitorar os processos de execução de ETL. Diferentemente de outros frameworks, o UnifiedViews possui suporte nativo à Dados abertos conectados e ontologias. O framework possui um mecanismo de agendamento de tarefas de extração de dados, permitindo ao usuário o acompanhamento dos resumos diários das tarefas executadas, bem como receber notificações sobre erros nas execuções de tarefas. Além disso, permite que usuários criem plugins customizados para estender as funcionalidades da ferramenta.
Open Refine(HAM,2013): Ferramenta de código aberto que permite a limpeza e transformação de grande volume de dados. Através de uma interface web, é possível realizar a extração, limpeza e transformação de arquivos em diversos formatos como CSV, TSV, XLS, XML e outros. A ferramenta permite também a realização de filtros e pesquisa nos dados, a identificação e remoção de conteúdo duplicados, vazios e inconsistentes.
DataWrangler (KANDEL et al., 2011): Ferramenta interativa desenvolvida pelas universidades de Stanford e Berkeley que auxilia os analistas de dados a realizem a limpeza e transformações complexas de dados de uma forma simplificada, minimizando a repetição e tarefas manuais. A ferramenta permite a transformação dos dados em um formato tabular
e, permite também, a exportação dos dados para ferramentas de análise de dados como R Studio, Tableau e outros.
FME Desktop (SAFE SOFTWARE, 2017): Ferramenta paga que permite a criação de fluxos de trabalho com poucos cliques através de uma interface drag-and-drop. A ferramenta permite a conversão, transformação, combinação, validação, projeção, filtragem e inspeção de dados através de mais de 450 ferramentas transformadoras de dados.
WIKIOLAPBASE (BERNARDO et al., 2017): Ferramenta colaborativa, de código aberto, que permite o processamento e a integração de dados abertos de diversas fontes. Permite também a realização de filtragem, agrupamento e junção de dados, tornando possível a análise de dados por usuários não técnicos. Os dados processados e integrados são disponibilizados em um formato compatível com ferramentas externas de visualização e análise de dados.
3.3
Publicação dos Dados nas Plataformas de Dados Abertos
Socrata DataSync (SOCRATA, 2017a): Solução multiplataforma, desenvolvida em Java, que automatiza a publicação de dados na plataforma Socrata. Além da possibili-dade de execução via linha de comando, a solução possui uma interface gráfica simples e fácil de utilizar a qual permite que usuários não técnicos publiquem os dados de forma simples e confiável. O carregamento dos dados no Socrata é feito através arquivos CSV ou de arquivos geoespaciais (geoJSON, KML, KMZ) localizados no disco rígido ou na rede. Além disso, a solução permite a integração com ferramentas de ETL, de agendamento de tarefas (Crontab) e processamento em lote de arquivos.
CKAN Resource Uploader for Pentaho Data Integration (Kettle) (
LO-CALIDATA, 2018): Extensão do Pentaho Data Integration (Kettle) que permite que os dados extraídos e transformados na ferramenta sejam enviados diretamente para o CKAN.
FME-CKAN (OPENCOUNCILDATA, 2017b): Extensão do FME-Desktop que
permite que os dados extraídos e transformados na ferramenta sejam enviados diretamente para o CKAN. Originalmente, a extensão foi desenvolvida para publicar os dados no Portal Australiano de Dados Abertos (data.gov.au) porém é possível customizá-la para permitir a automatização da publicação do dados em qualquer outro portal que utilize o CKAN.
CKAN-Upload (OPENCOUNCILDATA, 2017a): Ferramenta de linha de
co-mando desenvolvida em Python que automatiza o processo de atualização de um recurso existente em um conjunto de dados do CKAN. A ferramenta é destinada para a automati-zação da atualiautomati-zação periódica dos dados através de arquivos CSV.
CKAN Automator (OPEN NORTH, 2017): Biblioteca desenvolvida em Python que simplifica as operações de cadastro, atualização e exclusão em massa de organizações,
grupos e conjuntos de dados através da API do CKAN.
3.4
Comparativo entre as Ferramentas
Para a realização da comparação entre as ferramentas apresentadas nas seções acima, foram consideradas características e funcionalidades levando-se em conta, principalmente, o nível técnico exigido da equipe de TI, tanto nos conceitos e legislações a cerca dos dados abertos quanto no banco de dados dos sistemas de informação utilizados nas instituições. Nesse sentido, a comparação foi realizada considerando as funcionalidades necessárias para a automatização do processo de extração, publicação e atualização ] de dados abertos, dessa forma, facilitando a publicação e atualização3 dos dados abertos por um técnico de TI com pouco conhecimento sobre dados abertos.
3.4.1
Funcionalidades Desejadas
Considerando o processo de publicação e atualização dos dados abertos no CKAN, foram definidas as seguintes funcionalidades desejadas para a automatização do processo de extração e publicação de dados abertos: Configuração, Extração, Transformação, Descrição dos Dados, Carregamento, Agendamento de Tarefas, Registro de Execuções de Tarefas e Notificação. A seguir, será feito o detalhamento de cada uma dessas funcionalidades.
3.4.1.1 Configuração (CO)
A ferramenta deve permitir a realização das configurações relativas à integração com a instância do CKAN, relativas aos sistemas provedores de dados e as informações dos usuários responsáveis pela administração dos conjuntos de dados abertos.
3.4.1.2 Extração (E)
A ferramenta deve permitir a extração de dados a partir de diversas fontes como bancos de dados relacionais e não-relacionais (NoSQL), arquivos de planilhas eletrônicas, arquivos de texto, arquivos estruturados (XML e JSON) ou via serviços web (SOAP e REST).
3.4.1.3 Transformação (T)
Após extrair os dados, a ferramenta deve permitir a realização de transformações nos dados importados tais como realizar a conversão de tipos, a união ou exclusão de colunas e a transformação desses dados para os formatos abertos recomendados no Sistema de 5 estrelas apresentado na seção 2.2.
3.4.1.4 Descrição dos Dados (DD)
A ferramenta deve ser capaz de descrever os dados através de um dicionário de dados que contenha o tipo e uma descrição que caracterize os dados de cada campo dos dados. Esse dicionário de dados é necessário para ajudar os desenvolvedores e cidadão a entenderem e utilizar os dados de forma correta.
3.4.1.5 Carregamento (CA)
A ferramenta deve ser capaz de publicar os dados extraídos e transformados e os seus respectivos dicionários de dados diretamente no CKAN, inserindo novos recursos ou, quando necessário, atualizando os já existentes nos conjuntos de dados selecionados.
3.4.1.6 Agendamento de Tarefas (A)
A ferramenta deve permitir a execução periódica e automática de tarefas de extração, transformação e carregamento de dados a fim de manter os dados disponíveis no CKAN sempre atualizados.
3.4.1.7 Registro de Execução de Tarefas (L)
A ferramenta deve possuir um mecanismo de registro das execuções de tarefas que permita que os responsáveis técnicos possam realizar o acompanhamento dos resultados e se as execuções foram bem sucedidas ou não.
3.4.1.8 Notificação (N)
A ferramenta deve possuir um mecanismo de notificação via email que ao final de cada execução de uma tarefa notifique os responsáveis técnicos do sucesso ou falha da mesma.
3.4.2
Avaliação das Ferramentas
Cada uma das ferramentas foi avaliada e para cada uma das funcionalidades apresentadas acima foi atribuído um valor que indica o grau de satisfação da funcionalidade. Os valores possíveis são 0, +1 e +2 e representam, respectivamente: não atendeu, atendeu parcialmente e atendeu completamente. Dessa forma, cada uma das ferramentas poderia atingir até 16 pontos. O resultado da avaliação é apresentado na Tabela 4.
Tabela 4 – Avaliação das Ferramentas apresentadas nas seções 3.1, 3.2 e 3.3
Ferramenta (CO) (E) (T) (DD) (CA) (A) (L) (N) Total
Open Data Node +1 +2 +2 +2 +2 +2 +2 +2 15
UnifiedViews +1 +2 +2 +2 +1 +2 +2 +2 14
Pentaho Data Integration
-Kettle 0 +2 +2 0 +1 +2 +2 0 9
FME Desktop 0 +2 +2 0 +1 +1 +1 0 7
WPRDC-ETL +1 +1 +1 0 +2 0 +1 0 6
Open Data ETL Toolkit 0 +2 +2 0 0 +1 +1 0 6
Open Refine 0 +2 +2 0 0 0 +1 0 5 CKAN-Upload +1 +1 0 0 +2 0 0 0 4 CKAN Automator +1 +1 0 0 +2 0 0 0 4 Data Wrangler 0 +1 +2 0 0 0 0 0 3 WIKIOLAPBASE 0 +1 +1 +1 0 0 0 0 3 Socrata DataSync 0 +1 0 0 0 +1 +1 0 3
A Content-Driven ETL
Pro-cesses for Open Data 0 +1 +1 0 0 0 0 0 2
DataGraft 0 +1 +1 0 0 0 0 0 2
Fonte: Elaborada pelo autor.
A seguir serão apresentadas as justificativas a cerca da pontuação atribuída para cada uma das ferramentas:
• Configuração (CO): As ferramentas A Content-Driven ETL Processes for Open Data, Pentaho Data Integration - Kettle, Open Refine, Data Wrangler, FME Desktop, WIKIOLAPBASE e Socrata DataSync receberam o valor 0 pois são voltadas somente para a extração e transformação de dados. Já as ferramentas DataGraft, Open Data ETL Toolkit e Socrata DataSync também receberam 0 pois não possuem integração com o CKAN.
As ferramentas WPRDC-ETL, UnifiedViews, FME-CKAN, CKAN-Upload e CKAN Automator receberam +1 pois os dados da instância do CKAN (URL e API KEY) são passadas via linha de comando ou armazenadas em arquivos de configuração. O OpenData Node também recebeu +1 pois, apesar das configurações serem feitas através da interface gráfica da ferramenta, ela só permite a publicação dos dados em sua instância interna do CKAN.
• Extração (E): As ferramentas DataGraft, WPRDC-ETL, A Content-Driven ETL Processes for Open Data, Data Wrangler, WIKIOLAPBASE, Socrata DataSync, FME-CKAN, CKAN-Upload e CKAN Automator receberam +1 visto que suportam apenas a extração a partir de arquivos de planilha eletrônica ou texto.
Já as ferramentas Open Data Node, Open Data ETL Toolkit, Pentaho Data Integra-tion - Kettle, UnifiedViews, Open Refine e FME Desktop permitem que a extração de dados seja realizada a partir de diferentes fontes.
• Transformação (T): As ferramentas Socrata DataSync, FME-CKAN, CKAN-Upload, CKAN Automator receberam 0 visto que não possuem nenhum mecanismo de transformação de dados. As ferramentas DataGraft, WPRDC-ETL, A Content-Driven ETL Processes for Open Data e WIKIOLAPBASE receberam +1 pelo fato de permitir transformações simples de dados.
Já as ferramentas Open Data Node, Open Data ETL Toolkit, Pentaho Data Inte-gration - Kettle, UnifiedViews, Open Refine e FME Desktop permitem que sejam realizadas transformações de dados mais complexas.
• Descrição dos Dados (DD): As ferramentas WPRDC-ETL, Open Data ETL Toolkit, A Content-Driven ETL Processes for Open Data, Pentaho Data Integration - Kettle, Open Refine, Data Wrangler, FME Desktop não possui nenhum mecanismo
de descrição dos dados por isso recebeu 0.
A ferramenta WIKIOLAPBASE permite que os usuários descrevam seus dados através da interface da ferramenta, por esse motivo recebeu +1. Já as ferramentas Open Data Node e UnifiedViews permitem a descrição de dados através de metadados RDF, por isso receberam +2.
• Carregamento (CA): As ferramentas DataGraft, Open Data ETL Toolkit, A Content-Driven ETL Processes for Open Data, Open Refine, Data Wrangler, WI-KIOLAPBASE e Socrata DataSync receberam 0 pois não permitem o envio dos arquivos para o CKAN.
As ferramentas UnifiedViews, Pentaho Data Integration - Kettle e FME Desk-top receberam +1 devido à necessidade da utilização de extensões para permitir o envio dos arquivos para o CKAN. Já as ferramentas Open Data Node, WPRDC-ETL, CKAN-Upload, CKAN Automator receberam +2 pois permitem o envio de forma nativa dos arquivos diretamente para o CKAN.
• Agendamento de Tarefas (A): As ferramentas DataGraft, WPRDC-ETL, A Content-Driven ETL Processes for Open Data, Open Refine, Data Wrangler, WIKI-OLAPBASE, CKAN-Upload e CKAN Automator receberam 0 porque não possuem mecanismo de agendamento de tarefas.
+1 pois o agendamento de tarefas é feito através do crontab do Linux/MacOS ou agendador de tarefas do Windows.
Já as ferramentas Open Data Node, UnifiedViews e Pentaho Data Integration receberam +2 pelo fato de possuirem um agendador de tarefas nativo da ferramenta.
• Registro de Execução de Tarefas (L): As ferramentas DataGraft, A Content-Driven ETL Processes for Open Data, Data Wrangler, WIKIOLAPBASE e CKAN Automator receberam 0 pois não possuem mecanismo de acompanhamento da exe-cução da exeexe-cução das tarefas de extração.
As ferramentas WPRDC-ETL, Open Data ETL Toolkit, Pentaho Data Integra-tion - Kettle, Open Refine, FME Desktop, WIKIOLAPBASE, Socrata DataSync e FME-CKAN possuem um mecanismo simples de acompanhamento das tarefas de extração, por esse motivo receberam +1. Já as ferramentas Open Data Node e UnifiedViews possuem um mecanismo completo de acompanhamento por isso receberam +2.
• Notificação (N): Apenas as ferramentas Open Data Node e UnifiedViews possuem um mecanismo de notificação via email, por isso recebeu +2 e consequentemente, as outras ferramentas receberam 0.
3.4.3
Discussão dos Resultados
A partir da utilização e avaliação de cada uma das ferramentas apresentadas podemos concluir que a maioria delas automatizam parte do processo de ETL dos dados abertos porém pecam nos aspectos justificados na subseção anterior.
A ferramenta que mais se aproxima com o desejável para uma automatização de todo o processo é a Open Data Node, no entanto, seu principal problema é não permitir a publicação automática dos dados extraídos e transformados em instâncias já existentes do CKAN, ou seja, somente é possível utilizar essa funcionalidade na instância interna que a ferramenta dispõe. Dessa forma, caso as instituições públicas já possuam uma instância do CKAN instalada, a não seria o ideal. Além desse fator, a ferramenta exige que os técnicos de TI possuam um grau de conhecimento alto para que a configuração de todos os processos exigidos para atingir a automatização de todo o processo.
Além disso, outro fator negativo é que por ser uma ferramenta de uso genérico, cabe aos técnicos de TI o conhecimento das exigências da INDA e das legislações a cerca da política de dados abertos do governo federal brasileiro, o que fere o requisito de domínio D01, apresentado na seção 4.3.
Diante disso, é possível afirmar que tais ferramentas não agilizam completamente o processo de extração, transformação de dados abertos visto que é necessário a capacitação da equipe em cada um de seus procedimentos internos.
4 Proposta de Automatização do Processo
de Extração, publicação e atualização de
Dados Abertos
As Seções4.1,4.2 e 4.3apresentarão os requisitos funcionais, não funcionais e de domínio que nortearam o desenvolvimento da proposta de automatização do processo de extração, publicação e atualização de dados abertos. Tais requisitos foram elaborados com base nas funcionalidades desejadas apresentadas na Seção 3.4.
Na Seção 4.4 serão apresentadas as informações relativas à implementação da proposta de automatização a partir da integração de um sistema de informação já existente e a plataforma de dados abertos. Dessa forma, o SUAP foi utilizado como um estudo de caso para validar a proposta.
4.1
Requisitos Funcionais
A seguir serão apresentados os requisitos funcionais, ou sejam, as funcionalidades que são esperadas na proposta de automatização do processo de extração, publicação e atualização de dados abertos.
Tabela 5 – Requisitos funcionais da ferramenta proposta.
Cód. Nome Descrição
F01 Realizar o login
Realizar a autenticação no sistema através de credenciais de acesso previamente cadastradas pelo ad-ministrador do sistema
F02 Realizar a alteração de senha Permitir que o usuário altere sua senha
F03 Gerenciar Configurações do Sis-tema
Permitir o gerenciamento das con-figurações do sistema
F04 Gerenciar Grupos de Usuários Permitir o gerenciamento de gru-pos de usuários e suas permissões
F05 Gerenciar Usuários
Permitir o gerenciamento de usuá-rios, permissões e credenciais de acesso
F06 Gerenciar Organizações Permitir o gerenciamento das or-ganizações do CKAN.
F07 Gerenciar Grupos Permitir o gerenciamento dos gru-pos do CKAN
F08 Gerenciar Conjuntos de Dados Permitir o gerenciamento dos con-juntos de dados do CKAN
F09 Visualizar Históricos de Extração Permitir a visualização dos histó-ricos de extração de dados
F10 Agendar a extração de dados
Permitir o agendamento diário, se-manal, semestral ou anual da ex-tração automática de dados
Fonte: Elaborada pelo autor.
4.2
Requisitos Não Funcionais
A seguir serão apresentados os requisitos não funcionais, ou seja, as restrições da proposta de automatização do processo de extração, publicação e atualização de dados abertos.
Tabela 6 – Requisitos não funcionais da ferramenta proposta
Cód. Nome Descrição Categoria
FN01 Implementação O sistema deverá ser desenvolvido em
Python e utilizar o framework Django Obrigatório
FN02 Interoperabilidade O sistema deverá estar integrado às
APIs REST do CKAN Obrigatório
FN03 Interoperabilidade
O sistema deverá realizar a extração dos dados através das APIs existentes nos sistemas de informação da instituição
Obrigatório
FN04 Interoperabilidade
O sistema deverá realizar a extração dos dados através dos Bancos de Dados dos sistemas de informação existentes na instituição
Desejável
FN05 Responsivo A interface do sistema deve se adaptar
ao dispositivo utilizado pelo usuário Desejável
FN06 Compatibilidade O sistema deve ser compatível com o
maior número de versões do CKAN Desejável
FN07 Interoperabilidade
O usuário poderá realizar a autenticação através de suas credenciais de acesso dos sistemas de informação da instituição
Desejável
Fonte: Elaborada pelo autor.
4.3
Requisitos de Domínio
A seguir serão apresentados os requisitos de domínio, ou seja, as restrições impostas pela Política Nacional de Dados Abertos que definem as características da proposta de automatização do processo de extração, publicação e atualização de dados abertos.
Tabela 7 – Requisitos de domínio da ferramenta proposta.
Cód. Nome Descrição Categoria
D01 Política de Abertura de Da-dos
O sistema deve obedecer as nor-mas definidas no Decreto No 8777
e na Infraestrutura Nacional de Dados Abertos
Obrigatório
D02 Grau de abertura dos dados
Os dados devem ser disponibiliza-dos com um grau de abertura de pelo menos 3 estrelas
Obrigatório
D03 Formato dos dados disponi-bilizados
Os dados devem ser disponibili-zados, pelo menos, nos formatos CSV e JSON
Obrigatório
D04 Dicionário de Dados
Junto dos dados deve ser dispo-nibilizado o dicionário de dados contendo as informações necessá-rias para descrever os dados
Desejável
D05 Conexão entre os dados
Os dados devem estar conectados com outros dados a fim de dar uma semântica para eles
Desejável
Fonte: Elaborada pelo autor.
4.4
Implementação da Proposta de Automatização do Processo de
Extração, Publicação e Atualização de Dados Abertos
Esta seção apresenta a implementação da proposta de automatização do processo de extração, publicação e atualização de dados abertos a partir da integração entre um sistema de informação já existente e o CKAN.
Para isso, foram propostos cenários distintos que visavam avaliar a proposta de automatização sob a seguinte ótica: A intrusão de código no sistema de informação já existente versus a não dependência do sistema de informação para a realização da extração dos dados.
4.4.1
Cenários Propostos
A seguir, a seguir serão apresentados os cenários arquiteturais elaborados visando a integração entre o SUAP e o CKAN:
• 1o Cenário: Módulo criado dentro do SUAP que permite o gerenciamento, através da interface web, dos conjuntos de dados que serão publicados no formato aberto por cada um dos desenvolvedores responsáveis pelos módulos;
