Augusto Taboransky Pedro Jardim

Transcrição

1 UNIVERSIDADE FEDERAL DO ESTADO DO RIO DE JANEIRO CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA ESCOLA DE INFORMÁTICA APLICADA Uso de Tecnologia NoSQL para Extração de Informação sobre Unidades de Exploração e Produção de Petróleo Augusto Taboransky Pedro Jardim Orientador Profª. Geiza Maria Hamazaki Da Silva RIO DE JANEIRO, RJ BRASIL DEZEMBRO DE 2015

2 Uso de Tecnologia NoSQL para Extração de Informação sobre Unidades de Exploração e Produção de Petróleo AUGUSTO TABORANSKY PEDRO JARDIM Projeto de Graduação apresentado à Escola de Informática Aplicada da Universidade Federal do Estado do Rio de Janeiro (UNIRIO) para obtenção do título de Bacharel em Sistemas de Informação. Aprovada por: Profª. Drª. GEIZA M. HAMAZAKI DA SILVA (UNIRIO) Prof. Dr. ASTERIO KIYOSHI TANAKA (UNIRIO) Prof. Me. EDUARDO T.HADEU C. LEITE(Instituto Tecgraf/PUC-Rio) Me. PAULO IVSON (Instituto Tecgraf/PUC-Rio) RIO DE JANEIRO, RJ BRASIL DEZEMBRO DE

3 Agradecimentos Agradecemos a UNIRIO, seu corpo docente, direção e administração por todo o apoio nestes anos de conclusão do curso. Agradecemos ao Ministério da Ciência, Tecnologia e Inovação, ao Ministério da Educação, ao CNPQ e a CAPES, pela oportunidade a ambos de participar do programa Ciência Sem Fronteiras, que foi fundamental para a confecção deste trabalho, além de nos fornecer uma experiência única, que nos fez crescer como pessoa. Agradecemos a Prof a. Geiza pela paciência na orientação e incentivo que tornaram possível a conclusão deste trabalho. Agradecemos ao Instituto Tecgraf pela parceria na pesquisa dos dados utilizados para o estudo de caso neste trabalho. 3

4 Pedro Jardim Gostaria de agradecer a minha família e amigos próximos que estão sempre por perto para me ajudar nas horas de dificuldades. A todos os meus colegas da Faculdade, por esses anos de caminhada juntos, foram muitas aulas de revisão em cima da hora, trabalhos em grupo e desesperos por achar uma prova do período passado. Ao meu colega de trabalho Augusto Taboransky, com o qual iniciei junto meus anos de estudo de TI, cursando primeiramente um período em outra universidade e depois na UNIRIO. I'd also like to give a very special thanks to Dr. Bernadette Marie Byrne, who was my professor and tutor at Hertfordshire University during my time studying abroad. Who I had the opportunity to work with in a project also about NoSQL. 4

5 Augusto Almada Agradeço primeiramente a minha família por todo o suporte que me deram desde que nasci, em especial meus avós Ary e Aparecida, que foram meus segundos pais, e minha mãe, Maria Cristina, que sempre me apoiou e esteve ao meu lado. A todos os meus colegas de faculdade, que tornaram essa jornada acadêmica muito mais animada e menos sofrida. Muitas risadas demos juntos. A minha namorada, Evelina, que sempre me apoiou, tanto em minha jornada acadêmica na UNIRIO e na Halmstad University, quanto em meus desafios pessoais. Pelas risadas e choros, pelo carinho e por me ajudar a crescer como pessoa. Aos meus amigos de banda, Pedrito, Luiz, Lucas e Filipe, que também sempre estiveram ao meu lado, desde antes de ingressar a UNIRIO, e que certamente tiveram uma grande influência na minha personalidade. Ao meu amigo e parceiro de trabalho Pedro Jardim. Iniciamos essa jornada juntos, ambos tivemos nosso período no Ciência sem Fronteiras, e agora a terminamos juntos. Foi um prazer trabalhar ao seu lado. Esse não foi o primeiro trabalho que dividimos, e com sorte não será o último. 5

6 RESUMO Este trabalho aborda o uso da tecnologia NoSQL para armazenar e recuperar dados sobre o processo de pintura de plataformas de exploração de petróleo. O objetivo é estudar a viabilidade da utilização de um banco de dados NoSQL para conseguir reunir e analisar dados de diferentes fontes, e reuni-los em um único banco para conseguir inferir conhecimento sobre esse domínio. Os dados escolhidos referem-se a plantas industriais de plataformas de exploração de petróleo e foram obtidas pela parceria com o Instituto Tecgraf. Estes dados estão armazenados em diversas planilhas Excel. Neste trabalho é apresentado o estudo dessa tecnologia e também o desenvolvimento da aplicação em Java que visa transformar os dados dessas planilhas em informações úteis, como custo e tempo estimado para cada projeto. Palavras-chave: NoSQL, Banco de Dados, Ciência sem Fronteiras, Excel, Java 6

7 ABSTRACT This project discusses the use of the NoSQL technology to store and recover data about the process of painting oil and gas exploration platforms. The goal is to study the possibility of the use of NoSQL to gather and analyse data from different sources, and store them in a single database, to infer knowledge about this domain. The chosen data was about the area of oil and gas exploration platforms, and was obtained through cooperation with Instituto Tecgraf. This data is stored in several Excel spreadsheets. In this work it is presented a study of this technology as for the development of the Java application, which seeks to transform the data from these spreadsheets into applicable information, like the cost and estimated time for each project. Keywords: NoSQL, Database, Science without Borders, Excel, Java 7

8 Índice 1 Introdução Motivação Objetivos Organização do texto NoSQL Tecnologias aplicadas no projeto Desenvolvimento da Solução Estudo de caso Preparando o ambiente Etapas de desenvolvimento Leitura, tratamento e gravação Recuperação dos dados e processamento Criação dos arquivos.xls com as informações extraídas Consultas e Gráficos Conclusão e Trabalhos futuros

9 Índice de Figuras Figura 1: Exemplo de um DB collunar Figura 2: Exemplo de Key-value Figura 3: Exemplo da representação de dados em um Graph Store Figura 4: Exemplo de Document stores Figura 5: Diagrama de fluxo para ação de gravar os dados das planilhas para o banco de dados Figura 6: MongoDB shell script Figura 7: Exemplo de representação relacional no MongoDB Figura 8: Exemplo de um elemento agregado em MongoDB Figura 9: Visualização da divisão de um módulo Figura 10: Exemplo do banco de dados MongoDB rodando no prompt de comando Figura 11: Código da função de leitura dos arquivos Figura 12: Trecho do código usado para recuperar e tratar os dados Figura 13: Continuação da função lerarquivo, mostrando o tratamento do nome das zonas Figura 14: Exemplo de um elemento gravado no mongodb Figura 15: Código da função de busca da área total de cada módulo Figura 16: Resultado da busca do total da área de todos os setores por módulo Figura 17: Função que calcula o tempo levado para finalizar um setor Figura 18: Modelo da classe Registro Figura 19: Planilha gerada com os parâmetros: Trabalhadores: 30; Salário: R$50,00/dia; Duração: 30 dias Figura 20: Gerado com os parâmetros: Trabalhadores: 30; Salário: R$50,00/dia; Duração: 30 dias Figura 21: Gerado com os parâmetros: Trabalhadores: 50; Salário: R$50,00/dia; Duração: 18 dias Figura 22: Gerado com os parâmetros: Trabalhadores: 70; Salário: R$50,00/dia; Duração: 12 dias

10 1 Introdução 1.1 Motivação Com o advento da Internet iniciou-se uma nova era onde não só empresas são geradoras de dados, mas sim toda e qualquer pessoa conectada à rede. Estas geram uma grande quantidade de dados, que não estão estruturados, e vindo de diferentes fontes. Muitas empresas usam diferentes planilhas para armazenar e gerar dados, o que pode tornar complicado o cruzamento de dados entre elas, dado que para se obter essas informações é necessário a programação nas mesmas, ou uma pessoa realizar este processamento manualmente. Essas informações são essenciais para empresas, principalmente para levantamento de informações cruciais para o seu negócio 1. A transformação de dados puros em informação está presente no ramo de Business Intelligence 2 (BI). Isto é, conseguir juntar dados, tratar, gravá-los e processálos a fim de obter informações que ajudem as tomadas de decisão. Este trabalho não tem como objetivo criar um BI completo, mas sim abordar uma parte de sua estrutura, o armazenamento de dados e extração de informação. Tendo isto em vista, e se utilizando de dados do mundo real, é proposto mostrar a migração de dados gravados em planilhas para um banco de dados NoSQL, e o processamento e análise dos mesmos a fim de extrair informação, que serão visualizados em planilhas. 1 acessado em 14 dezembro acessado em 14 janeiro

11 1.2 Objetivos Este projeto objetiva apresentar um estudo de caso, com dados sobre áreas e elementos de uma plataforma de exploração de petróleo. Estes foram pesquisados em parceria com Instituto Tecgraf, da PUC-RIO, e sobre o qual deseja-se fazer cálculos e simulações, a fim de se extrair informações úteis para ajudar a análise sobre o custo de manutenção anticorrosiva em plataformas offshore. Os dados e as métricas levantadas são apenas para simulação, pois tratando-se de dados industriais de áreas estratégicas, é muito difícil a obtenção de informações reais, mas é consenso que qualquer resultado positivo, mesmo que mínimo, gera uma grande margem de lucro ou diminuição de custo em situações reais. 1.3 Organização do texto O presente trabalho está estruturado em capítulos e, além desta introdução, será desenvolvido da seguinte forma: Capítulo II: Descreve a tecnologia NoSQL, sua estrutura, e a compara ao esquema RDBMS. Capítulo III: Apresenta as tecnologias usadas no projeto e exibe a arquitetura do sistema desenvolvido. Capítulo IV: Detalha o procedimento realizado pelo sistema, desde a preparação do ambiente até os arquivos de saída. Capítulo V: Conclusões Reúne as considerações finais, assinala as contribuições da pesquisa e sugere possibilidades de aprofundamento posterior. 11

12 2 NoSQL Facebook 3, Youtube 4 e MercadoLivre 5 são alguns exemplos de plataformas online que possuem um grande volume de dados, podendo estes serem criados por grandes companhias, a fim de divulgar produtos ou serviço, ou por pessoas comuns que querem, por exemplo, compartilhar fotos de seu gato. São plataformas que possuem grandes quantidades de informações, na forma de texto, vídeo ou áudio. Com o desafio de conseguir armazenar esses dados não estruturados criaram-se os primeiros bancos de dados não relacionais, NoSQL. NoSQL significa Not Only SQL, e não Não SQL, como muitos acreditam. Alguns exemplos de bancos de dados NoSQL são: Oracle NoSQL 6, Apache Cassandra 7, Amazon DynamoDB 8, Google Bigtable 9 e MongoDB 10. O DynamoDB e Oracle NoSQL são do tipo key-value, Cassandra é um híbrido entre key-value e columnar e BigTable é columnar. O MongoDB, o banco escolhido para esse trabalho é do tipo Document store (NoSQL for Dummies, 2015). Estes modelos de dados serão apresentados a seguir. 3 acessado em 20 janeiro acessado em 20 janeiro acessado em 20 janeiro acessado em 3 janeiro acessado em 3 janeiro acessado em 3 janeiro acessado em 3 janeiro acessado em 3 janeiro

13 1 - Columnar Column stores são parecidos com o tradicional modelo relacional RDBMS (Relational Database Managemente System) (NoSQL for Dummies, 2015), onde há os conceitos de linha e coluna. Devem-se definir as colunas primeiro, o que significa que é necessário o conhecimento da estrutura dos dados com antecedência. Ele é comumente referido como Big Tables ou BigTable clones, por causa de seu ancestral o Google Bigtable. A diferença é que os dados não são armazenados nas linhas, horizontalmente, e sim nas colunas, verticalmente. Isso permite uma alta eficiência na compressão dos dados e fácil escalabilidade horizontal, tornando-o altamente otimizado para operações como count, sum e average. Figura 1: Exemplo de um DB collunar Key-value O Key-value utiliza o tradicional campo ID, como uma primary key, e um conjunto de dados. As funções de busca são muito rápidas devido a bons métodos de indexação presentes nesse modelo. Esse modelo funciona como um mapeamento, de um índice Key com um valor Value, que pode ser uma lista de outro mapeamento, possibilitando o armazenamento de uma árvore, podendo conter apenas um simples elemento, como números e textos, ou uma lista de elementos acessado em 19 dezembro

14 Figura 2: Exemplo de Key-value Graph stores Graph stores possuem pares de key-value interconectados e seguem a teoria do grafo com nós e arestas. Os nós são as entidades e os vértices mostram as relações entre eles. A forma é parecida com uma relação, mas a diferença para o modelo relacional está no seu custo, pois o modelo de grafos não se utiliza de joins e sim de Traversals techniques (Moniruzzaman & Hossain, 2013). Um exemplo é um banco de TripleStores, que são bancos de dados que buscam triplas se utilizando de consultas semânticas. A tripla é sempre composta por sujeito-predicado-objeto como João conhece Paulo (Graph Databases, 2013). Figura 3: Exemplo da representação de dados em um Graph Store acessado em 19 dezembro acessado em 19 dezembro

15 4 - Document stores Document stores também são chamados de aggregate databases, pois em um documento pode-se armazenar toda a informação em apenas um registro. Este possui um foco para Big Data, grandes quantidades de dados, e consultas eficientes, pois a extração de dados é simples, sem a necessidade de joins, sendo necessário apenas uma forma mais lógica para aplicações. O esquema não é previamente definido como nos bancos relacionais, pois a estrutura de dado é maleável, podendo um único elemento ter atributos inseridos ou retirados no decorrer do tempo, sem precisar mudar todos os outros dados. Figura 4: Exemplo de Document stores acessado em 19 dezembro

16 Diferença entre NoSQL e RDBMS. Existem diferenças entre NoSQL e os bancos de dados relacionais, entre elas a considerada mais importante é relacionada ao modelo de dados. Nos modelos relacionais é necessário, previamente, modelar os dados em tabelas e relações, o que pode acarretar em esforço extra para que todos os dados estejam organizados e armazenados de forma a representar duas relações. Com NoSQL, é apresentada uma abordagem Schemaless, ou seja, sem esquemas. Isso significa que não há um schema pré-determinado dos dados, logo, estes podem ser armazenados de forma desestruturada. Outra diferença é que os bancos de dados relacionais suportam as funções ACID, entanto NoSQL segue as propriedades BASE e o teorema CAP. Estas propriedades estão descritas abaixo: A.C.I.D significa Atomicity, Consistency, Isolation e Durable. A - Atomicity. neste contexto, atomicidade significa que uma transação é realizada por completo ou nada é realizado, All or nothing. Se uma pequena parte da transação falha, o sistema realiza um roll back para o estado inicial da transação. C - Consistency. Com esta propriedade, após uma transação bem sucedida a integridade dos dados estará preservada, ou seja, o banco de dados sempre estará consistente. Se uma transação falha em sua consistência o sistema retorna para o estado inicial, onde os dados estavam guardados de forma consistente. I - Isolation. Um banco de dados relacional pode receber diversas transações ao mesmo tempo, e para impedir que uma transação não interfira nos dados que 16

17 outra transação esteja precisando, o banco bloqueia o acesso aos dados até que todo o seu processo seja concluído. Assim, no início de uma transação os dados são isolados para que somente essa transação tenha acesso a eles. D - Durable. Os dados armazenados no banco devem ser duráveis, ou seja, eles devem permanecer guardados mesmo que haja falta de energia ou que o sistema pare. BASE significa Basic Avaiable, Soft State e Eventual Consistency. Basically Avaiable - Parte dos dados podem não estar sempre disponíveis para o usuário. Os bancos de dados NoSQL podem estar divididos em vários locais, e se um desses locais não estiver disponível o sistema não irá parar por esta causa. Soft State - O estado dos dados pode mudar a qualquer momento, e não há um impedimento para o acesso a esses dados. Assim, é possível acessar dados que estejam sendo usados por outras transações ao mesmo tempo. Eventually Consistent - O banco de dados não irá checar se as transações realizadas deixaram o banco em um estado consistente. Eric Brewer 15 foi o criador do teorema CAP (Consistency, Availability and Partitioning) nos anos Este teorema foi provado em 2002, deixando assim de ser uma teoria 16, e seu enunciado diz que não se pode ter os três atributos simultaneamente. Na maioria do tempo se terá dois atributos dos três acessado em 13 janeiro acessado em 13 janeiro

18 Consistency, neste contexto, não tem o mesmo significado que em ACID. De acordo com o teorema CAP, consistência significa que toda vez que os dados são escritos qualquer usuário que lê-los irá ver a última versão dos dados; Availability significa que o banco de dados sempre responderá quando for acionado; e Partitioning quer dizer que ao se ter vários bancos de dados espalhados, os bancos irão continuar a funcionar mesmo que um deles tenha ficado offline. Isto é, mesmo que um de seus bancos tenha parado de ser acessado pelos outros, estes não irão parar de gravar e vão continuar com suas rotinas. Assim podendo gerar inconsistência com seus dados, quando o banco que antes estava offline voltar a funcionar. Com o teorema CAP abre-se uma lista de opções em como balancear a consistência, disponibilidade e particionamento de seus dados em um banco de dados no sistema BASE. O que ajudou a melhorar o desenvolvimento de antigos e novos bancos de dados NoSQL. 18

19 3 Tecnologias aplicadas no projeto Para o desenvolvimento deste projeto foi utilizado como caso de uso um problema pesquisado pelo Instituto Tecgraf, no qual existem diversas planilhas de dados Excel com dados de plataformas petrolíferas, sobre pintura e manutenção das mesmas. Mais informações serão dadas na seção 4.1. Estas planilhas possuem os dados a serem cruzados a fim de retirar informações que ajudem as tomadas de decisões. Desta forma, utilizando a tecnologia NoSQL, os dados dessas planilhas são armazenados em um único Banco de Dados, e a partir dele são retiradas informações pertinentes. As tecnologias envolvidas nesse processo são: Planilhas Excel, Java e MongoDB. Para tratar as planilhas em que se encontram os dados brutos, será utilizada a linguagem Java, a fim de capturar e tratar esses dados, e então os armazenar no banco de dados MongoDB. A figura 5 representa o diagrama de fluxo de nossa aplicação para o fluxo de migração de dados das planilhas para o banco de dados. 19

20 Figura 5: Diagrama de fluxo para ação de gravar os dados das planilhas para o banco de dados No sistema, primeiramente os dados contidos nos arquivos com a extensão.xls são lidos, transformados e gravados no banco de dados do MongoDB. No passo seguinte é possível, através de queries (consultas), extrair os conhecimentos desejados e gerar outros arquivos (.xls) com estas informações. 20

21 Abaixo é apresentado um pouco mais sobre o MongoDB, supondo que o leitor possui conhecimento sobre as outras tecnologias. MongoDB Dentre todos os tipos de bancos de dados já mencionados no capítulo 2 será utilizado o MongoDB. Esta escolha foi feita principalmente por ela ser uma ferramenta open source. Também foi levando em conta a boa documentação encontrada sobre o assunto 17. No momento MongoDB é uma das ferramentas mais populares quando o assunto é banco de dados NoSQL. FourSquare, CartolaFC, NowTV, MTV, FORBES 18, são alguns exemplos desta popularidade. O tipo de armazenamento de dados é Document database. Nativamente o MongoDB usa JSON (JavaScript Object Notation) documents. JSON é um formato de dados de fácil leitura e compreensão para usuários. Este foi criado como base para a linguagem JavaScript. É apresentado no formato de texto e possui suporte para diversas linguagens de programação como C, C++, C#, Java, Python, Pearl, entre outras. O objeto JSON pode ser construído de duas formas. Uma com uma simples coleção de chave/valor, sendo muito parecido com um dicionário. Por exemplo: { nome : Pedro, Sobrenome : Jardim } 17 acessado em 17 novembro acessado em 17 novembro

22 Outra forma é com uma lista ordenada de valores, como um Array. Por exemplo: { usuarios : [ { nome : Pedro, Sobrenome : Jardim }, { nome : Augusto, Sobrenome : Taboransky } ] } A diferença entre as duas estruturas é sua complexidade para percorrer os dados. A primeira forma é um simples mapa de chave e valor, facilitando o entendimento e a forma de percorrer os dados. A segunda forma é mais complexa, pois nela é possível inserir formas de dados dentro de um simples elemento. Isto é, ter arrays dentro de elementos que já estão dentro de arrays. O que torna complicado percorrer toda a estrutura, pois ela pode ter vários arrays dentro de arrays. No momento, o MongoDB possui algumas interfaces amigáveis como por exemplo o NoSQL Manager for MongoDB 19. Outra característica é que ele suporta a 19 acessado em 11 janeiro

23 linguagem JavaScript, sendo assim possível criar scripts para serem processados pelo Banco De Dados. A figura 6 apresenta uma visão do shell do MongoDB. Através dele é possível visualizar seus dados e inserir comandos. Para o nosso projeto não foi necessário uma interface avançada, visto que a conexão com o banco é feita pela aplicação. Figura 6: MongoDB shell script Utilizando o MongoDB é possível utilizar duas abordagens para armazenar os seu dados: a relacional e a agregada. O armazenamento de forma relacional é muito parecido com o que é visto do tradicional banco de dados relacional. Todo objeto no MongoDB possui um 23

24 identificador único, muito parecido com uma primary key. Assim, é possível associar os elementos da mesma forma relacional de se possuir uma primary key e uma foreign key. Sendo assim possível associar diversos elementos, como mostrado na figura 7. Figura 7: Exemplo de representação relacional no MongoDB A vantagem dessa abordagem é de se conseguir relacionar os itens de uma forma a criar um conjunto de itens relacionados, muito parecido com o modelo usado pelos Bancos de Dados Relacionais. A desvantagem dessa abordagem é que no MongoDB não existem Joins entre os elementos. Sendo assim para se recuperar todos os elementos relacionados é necessário mais de uma consulta ao banco. Outra forma de se armazenar os dados é de forma agregada, isto é, juntar todos os dados em um único objeto. Por exemplo, ao invés de separar o usuário em um objeto, e seu endereço em outro, junta-se os dois em um único objeto. Isso pode acarretar em informações duplicadas, e por outro lado estará ganhando em performance, já que com apenas uma simples consulta é retornado todos os dados que se procura. A figura 8 é um exemplo desta abordagem. 24

25 Figura 8: Exemplo de um elemento agregado em MongoDB Na firgura 8, Embedded sub-document: significa sub-documento agregado, isto é, um document dentro de outro document. O método escolhido neste projeto foi o segundo, de forma agregada, pois todos os dados utilizados foram agrupados em um documento, e esses não possuem referências entre si. 25

26 4 Desenvolvimento da Solução 4.1. Estudo de caso Tendo os princípios da tecnologia estudados, é interessante aplicá-los, e para isso era necessário um conjunto de dados de um problema. Como citado anteriormente no capítulo 3, como caso de uso foi utilizado um problema pesquisado pelo Instituto Tecgraf, que aborda o processo de pintura anticorrosiva em plataformas offshore de exploração de petróleo. A divisão desta plataforma pode ser descrita da seguinte forma: Esta é dividida em módulos, que são divididos setores, que são divididos em zonas, que são divididos em sistemas, que por fim contém seus elementos, que possuem diversos valores, como nome, área, diâmetro, etc. 26

27 Figura 9: Visualização da divisão de um módulo A figura 9 auxilia o entendimento da divisão de um módulo. Cada andar desse módulo é denominado um setor, que é definido na figura pela união de todos os retângulos de cor verde. Cada setor possui diferentes zonas. Cada retângulo verde na figura é uma zona. Uma zona é definida pela área que uma pessoa consegue medir em um mês. E por fim, cada zona possui seus diferentes sistemas (e.g. tubulações, teto, suportes, etc). A pintura anticorrosiva é necessária pois esta plataforma está offshore, ou seja, em alto-mar, portanto esta pintura se torna importante, pois evitará ou dificultará futuras corrosões. Entretanto, esse planejamento não é uma tarefa fácil, devido à complexidade da estrutura, por exemplo esta possui uma limitação de pessoas embarcadas. É importante destacar que durante o processo de pintura a plataforma permanece inoperante, o que afeta diretamente o lucro da empresa. Além disso, há o custo do equipamento a ser utilizado e custo de pessoal, referente aos trabalhadores embarcados. Considerando todos esses fatores, torna-se importante a realização onshore da simulação e levantamento das operações a serem realizadas, pois é possível obter uma estimativa prévia do custo da operação. 27

28 4.2. Preparando o ambiente Nesta seção são descritos os passos necessários para preparar o ambiente de execução da aplicação. O primeiro passo é possuir o MongoDB 20, versão 3.0, instalado 21. Em seguida, é necessário obter o java JDK versão 7 ou superior 22. Como IDE foi utilizado o NetBeans, em conjunto com as seguintes bibliotecas: Drive para MongoDB no Java 23. Biblioteca para ler e escrever arquivos Excel para Java Etapas de desenvolvimento Leitura, tratamento e gravação Para executar a aplicação, é necessário iniciar o MongoDB. No trabalho ele é iniciado pelo Command Prompt (CMD). Ao abrir o Command Prompt basta digitar o comando: mongod, que inicializará o MongoDB, como pode ser observado na figura acessado em 10 novembro Instalação para o sistema operacional Windows acessado em 10 novembro acessado em 10 novembro acessado em 10 novembro acessado em 10 novembro

29 Figura 10: Exemplo do banco de dados MongoDB rodando no prompt de comando O primeiro passo da aplicação é o carregamento de dados no MongoDB. Para isso, a aplicação lê os arquivos.xls fornecidos e faz um tratamento nos dados para depois gravá-los no banco de dados. Na figura 11 é apresentado um trecho do código que obtém e tratam os dados. public static void leituradearquivos(mongodatabase db) throws IOException, BiffException { File folder = new File("src/arquivosPlataforma"); File[] listoffiles = folder.listfiles(); MongoCollection mycollection = db.getcollection("pt"); mycollection.drop(); } for (File file : listoffiles) { if (file.isfile()) { lerarquivo(db, file.getname()); } } Figura 11: Código da função de leitura dos arquivos 29

30 A aplicação lê todos os arquivos, planilhas usadas na análise, que estão na pasta de origem. Como o código mostrado acima, a função obtém o nome de todos os arquivos que estão na pasta especificada. Depois seleciona-se a collection, tratada aqui por pt, para que se limpe todos os dados que possam estar gravados nela, esta ação é apenas uma precaução para que a collection esteja vazia ao inicio das gravações. Tendo os endereços dos arquivos, inicia-se um loop percorrendo cada arquivo encontrado, para que seus dados sejam lidos, tratados e gravados no banco de dados. Figura 12: Trecho do código usado para recuperar e tratar os dados 30

31 Figura 13: Continuação da função lerarquivo, mostrando o tratamento do nome das zonas Após abrir o arquivo, é definido um loop para percorrer todas as células do arquivo, como mostram as figura 12 e 13. Para cada linha é feito um tratamento nos dados para que estes possam ser gravados no MongoDB. Este é realizado com o objetivo de facilitar as futuras queries, pois nem todos os nomes e dados estão apresentados de forma homogênea, tendo pequenas diferenças quanto a letras maiúsculas e minúsculas. Por exemplo: zona A e Zona A, sendo os dois a mesma zona. Após o tratamento os dados são salvos no MongoDB. A figura 14 apresenta um exemplo de como os dados estão armazenados. 31

32 Figura 14: Exemplo de um elemento gravado no mongodb Para poder tratar os dados e gravá-los, foi necessário compreender a divisão de uma plataforma de petróleo além dos dados disponíveis nas planilhas. Com base nos que foi explicado anteriormente pode-se entender que: - Cada plataforma é dividida em Módulos (identificado por modulo no objeto mostrado na figura 14 ); - Cada Módulo é dividido em Setores (identificado por setor no objeto mostrado na figura 14); - Cada Setor é divido em Zonas (identificado por subgrupo-zona no objeto mostrado na figura 14); - Cada Zona é divida em Sistemas (identificado por #subgrupo no objeto 32

33 mostrado na figura 14 ). Tempo de gravação: O tempo médio que o programa leva para ler todos os arquivos XLS, 27 arquivos com um total de 37.6 MB, tratar e gravar no banco é de : 56 segundos O teste foi feito em um laptop ASUS i GHz GB de ram Recuperação dos dados e processamento Com os dados tratados e gravados no MongoDB, o próximo passo é recuperá-los e processá-los de forma a gerar novas informações. O foco, nesta parte, é conseguir cruzar os dados de diferentes setores dos diversos módulos, e inferir métricas a fim de descobrir o gasto total de cada setor em variação ao número de trabalhadores, e o quanto é pago por hora para cada um. Para os cálculos foram utilizadas as seguintes métricas: 1. Tratamento de superfície WJ-2 = (onshore: 1 USP/m2 ou offshore: 1,25 USP/m2) x 115 x m2 x 0,2 (reais) WJ-3 = (onshore: 0,75 USP/m2 ou offshore: 1 USP/m2) x 115 x m2 x 0,8 (reais) O somatório das duas equações acima dá o custo total do tratamento de superfície. Nota: USP = Unidade de Serviço de Pintura 33

34 WJ é uma forma tratamento da superfície utilizando-se um hidrojato Aplicação da tinta de alto desempenho Valor = R$ 112,00 x m2 = total da tinta (reais) m2 = metros quadrados. 3. Equipamento Máquina de hidrojato = R$ 3250,28 x dia (reais) dia = dias de trabalho R$ 3250,28 é o preço do aluguel do equipamento. 4. Custo por trabalhador Salário = horas trabalhadas por dia x valor da hora x dias O custo total é dado por: Tratamento de superfície + Aplicação da tinta de alto desempenho + Equipamento + Preço por trabalhador. É preciso ressaltar que estas métricas são simulações, pois como se tratam de dados industriais de um setor sensível, não foi encontrado as reais métricas e valores de mercado. Inicialmente precisa-se recuperar os dados do MongoDB. O objetivo é obter os dados referentes à área total de cada setor por cada módulo. A query apropriada para obtenção destes dados em comando shell no MongoDB é: 25 acessado em 10 janeiro

35 db.pt.aggregate([ $group:{_id: { "modulo" : "$modulo", "setor " : "$setor"}, total: {$sum : "$area"} } }, { $sort: { modulo: -1 }} ]); A mesma query em SQL agrupará os dados pelos atributos modulo e setor ( GROUP BY ), somando o atributo area ( SUM ), e ordenando pelo atributo modulo ( ORDER BY ). Na figura 15 segue a implementação em Java. 35

36 private static List<Object> retornaresultadoquerycomdoisparametros(string nomemodulo, String nomesetor){ MongoCollection<Document> ptcollection = initiatemongocollection(); AggregateIterable<Document> agg = ptcollection.aggregate(aslist( new Document("$match",new Document("modulo",java.util.regex.Pattern.compile("^.*$"))), new Document("$group",new Document("_id",new Document(nomeModulo,"$"+nomeModulo).append(nomeSetor,"$"+nomeSetor)).append("Total", new Document("$sum","$area"))), new Document("$sort", new Document("Total",1)) )); List<Object> listo = new ArrayList<>(); agg.foreach(new Block<Document>() public void apply(final Document document) { int control = 1; for(object o : document.values()) { if(control==1){ Document aux = (Document) document.get("_id"); String modaux = aux.getstring(nomemodulo); String setaux = aux.getstring(nomesetor); listo.add(modaux); listo.add(setaux); control = 2; } else { listo.add(document.getdouble("total")); control = 1; } } } }); return listo; } Figura 15: Código da função de busca da área total de cada módulo 36

37 As consultas escritas no shell do MongoDB e em Java têm o mesmo objetivo: agregar todos os setores por módulos e somar suas áreas. O retorno para tal busca, ilustrado na figura 16, é o mesmo nos dois formatos. Figura 16: Resultado da busca do total da área de todos os setores por módulo Tendo a lista de cada setor por módulo e a área total de cada um, é inicializado o processo de cálculo, utilizando as métricas citadas anteriormente. Foi calculado o tratamento de superfície, quantidade de tinta de alto desempenho usada, aluguel do equipamento e salário de todos os funcionários no espaço de tempo necessário para concluir a obra. Além disso, para se ter o custo total, é necessário saber o quanto será gasto com 37

38 o custo de pessoal, que é dado pelo tempo de trabalho dos funcionários. Na métrica utilizada para a simulação foi estipulado o valor de 30 trabalhadores, que levam 30 dias para concluir a pintura de um setor. Utilizando essa informação como média, foi calculado quanto tempo N trabalhadores levariam para pintar cada módulo, sendo N um número inteiro positivo qualquer. Assim será obtido o tempo de pintura, que será necessário para calcular o preço total de cada setor. O número de trabalhadores pode ser inserido pelo usuário, a fim de descobrir quanto a mais será gasto na pintura, e quanto tempo levará para terminar o setor. Vale ressaltar que essa métrica é limitada, pois está sujeita a limitações físicas e espaciais do ambiente. Figura 17: Função que calcula o tempo levado para finalizar um setor Se tratando de uma simples aplicação, não foi necessário criar várias classes para armazenar os dados tratados. Para guardar as informações tradadas do total da área de cada setor por módulo foi criado uma classe de domínio chamada Registro, que armazena o nome do setor, o nome do modulo, a área total e os preços de cada item da métrica utilizada. A figura 18 apresenta representação desta classe, seguindo o modelo UML para diagrama de classe. 38

39 Figura 18: Modelo da classe Registro 39

40 Criação dos arquivos.xls com as informações extraídas Após obter a informação de cada setor, é formada uma lista de Registros, com os dados obtidos, a partir da qual gera-se o arquivo.xls apresentando todos os valores referentes ao cálculo do preço total de um setor, utilizando as variáveis quantidade de trabalhadores e salário do trabalhador por hora além da métrica para cálculo de pintura offshore. Figura 19: Planilha gerada com os parâmetros: Trabalhadores: 30; Salário: R$50,00/dia; Duração: 30 dias (Anexo B: ResultadoModuloSetor-30h-50s.xls) 40

41 Consultas e Gráficos Após a implementação da aplicação, o passo seguinte são as simulações com diferentes valores para a quantidade de trabalhadores e valor pago a esses por hora, a fim de calcular o custo total da pintura e a quantidade de dias que tal obra poderá levar. Os gráficos, presentes na figuras 20, 21 e 22, foram gerados com os valores encontrados nas planilhas no Anexo B:Arquivos de saída. Figura 20: Gerado com os parâmetros: Trabalhadores: 30; Salário: R$50,00/dia; Duração: 30 dias; (Anexo B: ResultadoModuloSetor-30h-50s.xls) 41

42 Figura 21: Gerado com os parâmetros: Trabalhadores: 50; Salário: R$50,00/dia; Duração: 18 dias; (Anexo B: ResultadoModuloSetor-50h-50s.xls) 42

43 Figura 22: Gerado com os parâmetros: Trabalhadores: 70; Salário: R$50,00/dia; Duração: 12 dias; (Anexo B: ResultadoModuloSetor-70h-50s.xls) Comparando os gráficos das figuras 20 e 21, é perceptível que o custo total é praticamente o mesmo, mas a quantidade de dias necessários é menor, ou seja, o trabalho seria finalizado com antecedência. A contratação de mais trabalhadores agiliza a pintura, diminuindo assim o tempo de aluguel das máquinas. O preço da tinta, neste caso, não se altera. Essa é uma informação importante para a empresa, pois torna possível prever gastos, entre outras métricas. Sendo que para realizar a manutenção e pintura anticorrosiva da plataforma, esta fica parada, não realizando seu trabalho. Assim, descobrir que há uma forma de diminuir esse tempo de ócio é de grande relevância. 43

44 5 Conclusão e Trabalhos futuros Após a realização do trabalho foi percebida a possibilidade da utilização da tecnologia NoSQL para migrar dados de planilhas Excel para um banco de dados não relacional, e conseguir extrair informações destes, para que se possa inferir conhecimento sobre os dados obtidos. A não necessidade de se ter um esquema de dados definido foi fundamental para a rápida implementação da aplicação. Essa flexibilidade em relação aos bancos de dados relacionais fez com que o início da execução do trabalho realizada com maior rapidez, pois o banco NoSQL consegue se adaptar facilmente aos dados fornecidos. Para modelar os dados apresentados em um banco de dados relacional, seriam necessárias no mínimo 5 tabelas: Modulo, Setor, Zona, Sistema e atributos. Logo, seriam 5 tabelas para manter, além de que, para retirar informações como a área de setores por módulo, a operação de join ocorreria entre 3 tabelas. Outro fator importante é com relação aos atributos, pois nas planilhas fornecidas, muitos elementos não possuem certos atributos, pois não fazem parte de suas características. No modelo relacional a tabela atributos teria muitos campos null, enquanto no MongoDB o campo apenas não é registrado. Como mencionado anteriormente, este trabalho de levantamento de dados e análise era realizado manualmente. Com a aplicação desenvolvida neste projeto, o que uma pessoa levaria dias para concluir, pode ser realizado em minutos. Além disso, é 44

45 eliminada a ocorrência de erro humano, que pode acontecer no processamento dos dados, quando realizado manualmente. Utilizando a aplicação, o usuário fica responsável apenas pela interpretação dos resultados. Como sugestão para trabalhos futuros, tendo os dados completos sobre as plataformas e as métricas reais usadas, há a possibilidade de se estender essa ferramenta para responder outras consultas, ou para cruzar dados entre tabelas distintas, isto é, o programa ler duas tabelas distintas e através dos tipos encontrados nas colunas retornar os possíveis cruzamentos entre as mesmas. Vale observar que os dados aqui usados foram extraídos apenas de uma das plataformas de petróleo. Um possível trabalho futuro poderia comparar diferentes plataformas de petróleo existentes. Como mencionado anteriormente, este é apenas um protótipo, com apenas algumas consultas e sem uma interface amigável, sendo assim aperfeiçoamento da ferramenta com o desenvolvimento de uma interface para o usuário com a possibilidade de criar outras consultas que abrangem outros atributos seria interessante. Realizando assim um Business Intelligence (BI), um sistema que combina junção de dados, armazenamento e processamento dos dados e aplicação de conhecimento sobre ele para a extração de informações importantes para a tomada de decisão 26. Vale ressaltar que é interessante uma análise de desempenho comparando o banco de dados relacional e o banco NoSQL acessado em 25 janeiro

46 Referências Bibliográficas Atzeni, P. (2013) The relational model is dead, SQL is dead, and I don t feel so good myself. acessado em Dezembro Bartholomew, D. (2010) SQL vs NoSQL acessado em Dezembro Fowler, Adam (2015), NoSQL for dummies, Wiley Brand, 1 th edition. Nance, C. (2013) NoSQL vs RDBMS, why there is a room for both. acessado em Dezembro Robinson, Ian and Webber, Jim and Eifrem, Emil (2013). Graph Databases, O Reilly s, 2 nd edition. Sharma V. and Dave M. (2012). SQL and NoSQL Databases. International Journal of Advanced Research in Computer Science and Software Engineering, pages acessado em Dezembro Sherman, R. (2009). BI tools vs. Microsoft Excel spreadsheets acessado em Dezembro

47 Anexos Anexo A: Arquivos de entrada P_M02_S01.xls P_M04_S01.xls P_M04_S02.xls P_M04_S03.xls P_M04_S04.xls P_M05_S01.xls P_M05_S02.xls P_M05_S03.xls P_M07_S01.xls P_M07_S02.xls P_M07_S03.xls P_M07_S04.xls P_M09A_S01.xls P_M09A_S02.xls P_M09B_S01.xls P_M09B_S02.xls P_M10_S01.xls P_M10_S02.xls P_M17_S01.xls P_M24_S01.xls P_M25_S01.xls P_M30_S01.xls P_M34_S01.xls P_M35_S01.xls P_M37_S01.xls P_M45_S01.xls P_M49_S01.xls 47

48 Anexo B: Arquivos de saída Resultado-Modulo-Setor-Zona.xls ResultadoModuloSetor-30h-50s.xls ResultadoModuloSetor-50h-50s.xls ResultadoModuloSetor-70h-50s.xls 48