DANIEL SOUZA RAMOS
USO DE UM BANCO DE DADOS ORIENTADO A DOCUMENTOS PARA SUPORTE A APLICAÇÕES DE BIG DATA:
UM EXPERIMENTO UTILIZANDO DADOS DA WEB 2.0
Palhoça 2014
USO DE UM BANCO DE DADOS ORIENTADO A DOCUMENTOS PARA SUPORTE A APLICAÇÕES DE BIG DATA:
UM EXPERIMENTO UTILIZANDO DADOS DA WEB 2.0
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação.
Orientador: Prof. Flavio Ceci, M. Eng.
Palhoça 2014
USO DE UM BANCO DE DADOS ORIENTADO A DOCUMENTOS PARA SUPORTE A APLICAÇÕES DE BIG DATA:
UM EXPERIMENTO UTILIZANDO DADOS DA WEB 2.0
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina.
Dedico este trabalho a minha mãe Nilva, a responsável por minha formação, que sempre esteve presente me dando todo o apoio e motivação para seguir em frente.
Ao meu amigo e orientador, professor Flavio Ceci, pela amizade e, por toda a dedicação e atenção empenhadas no auxílio a elaboração deste trabalho. A tranquilidade repassada foi essencial para que eu pudesse chegar ao fim desta etapa.
A todos os professores do Curso de Sistemas de Informação da Universidade do Sul de Santa Catarina por me auxiliarem ao longo desta jornada.
Vive-se uma constante evolução tecnológica e um grande crescimento no volume de dados gerados pelas aplicações web, devido principalmente a popularização das redes sociais e a acessibilidade dos dispositivos móveis, cada um de nós vem se tornando um gerador de informações. Há um crescimento sem precedentes no volume de dados disponíveis atualmente, e junto com esse crescimento, a demanda por soluções mais eficientes para lidar com essa nova realidade, em que os dados são mais volumosos, variados e mais rápidos do que as atuais soluções de gerenciamento de dados costumavam lidar. Diante desse cenário, o objetivo do presente trabalho foi modelar e implementar uma base de dados orientada a documentos como proposta de solução. Com este fim, foi desenvolvido um protótipo utilizando um banco de dados orientado a documentos com dados provenientes da Web 2.0. O resultado atingido com o experimento atendeu os objetivos a que se propôs, demonstrando a viabilidade e benefícios da utilização de um banco de dados orientado a documentos para suporte a aplicações de Big Data.
We live in a constant technological evolution and large growth of data volume generated by web applications, mainly due to the popularity of social networks and the accessibility of mobile devices, each of us has become an information generator. There is an unprecedented growth in volume of data available today, and along with this growth, the demand for more efficient solutions to deal with this new reality, in which the data are more voluminous, varied and faster than current data management solutions used to handle. Given this scenario, the goal of this work was to model and implement a document oriented database as a proposed solution. To this end, a prototype was developed using a document oriented database with data coming from Web 2.0.
The results achieved with the experiment met the goals it has set, demonstrating the feasibility and benefits of using a document oriented database to support Big Data applications.
Figura 1 - Exemplo de documento ... 25
Figura 2 – Exemplo de documento semelhante ... 26
Figura 3 - Relação de Bancos de Dados e seus protocolos de acesso correspondentes ... 27
Figura 4 - Exemplo de relacionamento embutido no formato JSON ... 28
Figura 5 - Etapas ... 33
Figura 6 - Desenho da Solução ... 34
Figura 7 - Fluxograma de Modelagem ... 38
Figura 8 - Modelo de Caso de Uso ... 41
Figura 9 - Descrição dos Casos de Uso ... 42
Figura 10 - Modelo de Domínio ... 43
Figura 11 - Modelo E.R ... 44
Figura 12 - Modelo Orientado a Documento... 44
Figura 13 - Modelo Orientado a Documento... 45
Figura 14 - Ferramentas Tecnológicas ... 46
Figura 15 - Captação de dados ... 56
Figura 16 - Consulta de dados ... 58
Figura 17 - Tela de consulta de tweets por tag ... 59
Figura 18 - Tela de consulta tweets por usuário ... 60
Figura 19 - Tela consulta tweets por hora ... 60
Figura 20 - Tela consulta por tag com o filtro “Aécio” ... 61
Figura 21- Tela consulta por tag com o filtro “Dilma” ... 62
Figura 22 - Quantidade de entrevistados por gênero ... 65
Figura 23 - Quantidade de entrevistados por formação ... 66
Figura 24 - Questão 1 ... 66 Figura 25 - Questão 2 ... 67 Figura 26 - Questão 3 ... 67 Figura 27 - Questão 4 ... 68 Figura 28 - Questão 5 ... 68 Figura 29 - Questão 6 ... 69 Figura 30 - Questão 7 ... 70 Figura 31 - Questão 8 ... 70 Figura 32 - Questão 9 ... 71 Figura 33 - Questão 10 ... 71 Figura 34 - Cronograma ... 82
Quadro 1 - Requisitos Funcionais ... 40 Quadro 2 - Requisitos Não Funcionais ... 40
1 INTRODUÇÃO ... 12 PROBLEMA ...13 1.1 OBJETIVOS ...14 1.2 1.2.1 Objetivo Geral ...15 1.2.2 Objetivos Específicos: ...15 JUSTIFICATIVA ...15 1.3 ESTRUTURA DA MONOGRAFIA ...16 1.4 2 REFERENCIAL BIBLIOGRÁFICO ... 17 MODELAGEM DE DADOS ...17 2.1 2.1.1 Relacional ...18 2.1.2 Dimensional ...20 2.1.3 NoSQL ...21
BANCO DE DADOS ORIENTADO A DOCUMENTO ...24
2.2 WEB 2.0...28 2.3 BIG DATA ...30 2.4 3 MÉTODO... 31
CARACTERIZAÇÃO DO TIPO DE PESQUISA ...31
3.1 ETAPAS METODOLÓGICAS ...32 3.2 DESENHO DA SOLUÇÃO ...33 3.3 DELIMITAÇÕES ...34 3.4 4 MODELAGEM ... 36 UML ...36 4.1 MÉTODO DEFINIDO PARA MODELAGEM ...38
4.2 MODELAGEM PROPOSTA ...39 4.3 4.3.1 Cenário de aplicação ...39 4.3.2 Levantamento de Requisitos ...40 4.3.3 Casos de Uso ...41 4.3.4 Modelo de Domínio ...42 4.3.5 Modelo E.R ...43
4.3.6 Modelo Orientado a Documento ...44
5 DESENVOLVIMENTO ... 46 FERRAMENTAS TECNOLÓGICAS ...46 5.1 5.1.1 Apache HTTP Server ...47 5.1.2 PHP ...47 5.1.3 Sublime Text ...48 5.1.4 JSON ...48 5.1.5 ExtJS ...49 5.1.6 Eclipse ...49 5.1.7 Twitter ...50 5.1.8 MongoDB ...50 HISTÓRICO DE DESENVOLVIMENTO ...51 5.2 EXPERIMENTO ...55 5.3 5.3.1 Cenário ...55 5.3.2 Protótipo de Desenvolvido ...56 AVALIAÇÃO ...62 5.4 5.4.1 Análise de uso do protótipo ...63
6 CONCLUSÕES E TRABALHOS FUTUROS... 73 CONCLUSÃO ...73 6.1 TRABALHOS FUTUROS ...75 6.2 REFERÊNCIAS ... 77
1 INTRODUÇÃO
Em torno de 2005, teve início uma drástica mudança na maneira que as pessoas interagem com a informação na internet. Com o avanço da tecnologia dos dispositivos móveis cada vez mais poderosos e conectados que em conjunto com o crescimento das redes sociais vem aumentando a quantidade de conteúdo produzido pelos usuários, causando um grande impacto na sociedade e nas organizações. Nas últimas décadas, as organizações começaram gradualmente a gastar mais tempo, dinheiro e esforços gerenciando seus dados, mas esses esforços eram geralmente de natureza interna. (SIMON, 2013).
Com a chegada da Web 2.0, isso começou a mudar, como resultado direto, os dados cresceram exponencialmente em volume, variedade e velocidade, tendo como principal colaborador o crescente surgimento das redes sociais, como o Facebook, Twitter, Flickr e YouTube. Mais e mais pessoas estão andando por aí com seus dispositivos cada vez mais poderosos e avançados. Em conjunto, esses sites e avanços levaram a uma proliferação de dados não estruturados e semiestruturados. (SIMON, 2013).
Segundo O´Reilly (2005), o conceito de “Web 2.0” começou com uma conferência de brainstorming entre O´Reilly e MediaLive International, destaca o aproveitamento da inteligência coletiva como diferencial competitivo.
Com todos esses novos avanços e recursos colaborativos de interação do usuário e compartilhamento de diferentes tipos de dados, como texto, foto e vídeo, o usuário passou a não ser mais um simples consumidor de informação, mas também um grande produtor.
A análise e gerenciamento das informações geradas a partir das contribuições dos usuários passaram a ter um papel de extrema importância na tomada de decisão das organizações. Nessa nova realidade, as organizações começaram a ver seus dados crescerem em velocidade e volume, e, diante dessa emergente demanda de escalabilidade e disponibilidade da informação devido às limitações técnicas dos atuais bancos de dados relacionais, muitas delas desenvolveram suas próprias soluções de armazenamento, que são hoje classificadas como banco de dados NoSQL.
Segundo Vaish (2013), NoSQL (normalmente interpretado como “not only sql”) na computação se refere a uma vasta classe de SGBD´s identificados por não seguirem o mesmo modelo de dados dos famosos bancos de dados relacionais (SGBDR´s).
Este capítulo está organizado em Problema, Objetivos, Objetivo Geral e Específicos, Justificativa e, por fim, Estrutura da monografia.
PROBLEMA 1.1
Vive-se uma constante evolução tecnológica e um grande crescimento no volume de dados gerados pelas aplicações web que disponibilizam os mais variados tipos de informação, impulsionados pela vasta utilização de dispositivos como celulares, tablets e computadores portáteis, que, tendo um preço cada vez mais acessível, são capazes de individualmente gerar uma grande quantidade de dados, permitindo-nos, por exemplo, interagir nas redes sociais, publicando fotos, mensagens, localização ou acessar mapas, ler escrever e-mails a qualquer hora e qualquer lugar, tornando-nos geradores ambulantes de informação.
Para se ter uma ideia em números, o Google, sozinho, processa por dia cerca de 24 petabytes de dados todo dia. (DAVENPORT; BARTH; BEAN, 2012). O Facebook revelou que processa por dia mais de 500 terabytes de dados, recebe 2.7 bilhões de “curtidas”, 300 milhões de fotos e examina a cada meia hora, cerca de 105 terabytes de dados. (CONSTINE, 2012).
Apesar de ser uma consequência da evolução e disponibilidade da tecnologia, esse crescimento exponencial na quantidade de dados produzidos, passa a ser um problema para as organizações, já que, por serem tão volumosos e não estruturados, excedem a capacidade de análise e gerenciamento dos bancos de dados convencionais. Dados não estruturados são tipicamente informações não organizadas, que podem ser e-mails, áudio, vídeo e dados das redes sociais, como exemplo. (DAVENPORT; BARTH; BEAN, 2012).
Para suportar o grande volume e variedade de dados e responder às milhares de requisições de leitura e escrita em um tempo satisfatório, as modernas aplicações web precisam ser altamente escaláveis e possuir um esquema de dados flexível, caracterizando tais aplicações no conceito de “Big Data”, que não se aplica aos bancos de dados relacionais. (NANCE, 2013).
Dentre as diversas definições encontradas na internet, podemos sucintamente afirmar que “Big Data” é um termo utilizado pra descrever esse crescimento exponencial da informação, caracterizado pelo seu grande volume, variedade e velocidade. (SIMON, 2013).
Os bancos de dados relacionais são facilmente escaláveis verticalmente (quando uma única máquina tem seu poder de hardware melhorado), inviável para aplicações que precisam lidar com um grande volume de dados. Para atender as necessidades de tais
aplicações, o banco de dados precisa ser escalável horizontalmente (quando é aumentado o número de máquinas), que, no caso dos bancos de dados relacionais, é necessária a adição de máquinas muito robustas, complexas e extremamente caras que não atendem as necessidades de desempenho esperadas. Outro contra ponto dos bancos relacionais é o seu restrito esquema de dados, incompatível com a flexibilidade necessária para lidar com os mais variados tipos de dados não estruturados disponibilizados por um número crescente de diferentes fontes de informação. (SANTANA, 2013).
É inegável que a informação é um bem de valor inestimável para as organizações, que estão mergulhando em um mar de dados em constante expansão. A crescente abundância de informação está fazendo com que as organizações comecem a pensar em termos de fluxo e processo contínuo no que diz respeito a coleta, análise e interpretação de dados, enfatizando a importância da tecnologia nos principais processos de negócio da organização, em que a agilidade no processamento da informação tem se tornado um fator competitivo cada vez mais decisivo.
O crescente volume de dados requer uma modernização das atuais tecnologias, dentre outras necessidades, podemos destacar:
• melhores formas de armazenamento de grande quantidade de dados;
• estrutura de dados mais eficientes para organizar e recuperar a informação;
• estratégias otimizadas para a análise de grande quantidade de dados. O presente trabalho tem como foco analisar o uso dos bancos orientados a documentos como resposta às necessidades apresentadas anteriormente. A próxima seção apresenta os objetivos geral e específicos deste trabalho.
OBJETIVOS 1.2
Esta seção tem como foco apresentar os objetivos principais deste trabalho, na forma de um objetivo geral e objetivos específicos.
1.2.1 Objetivo Geral
Modelar e implementar uma base de dados orientada a documento, a fim de simular um ambiente que possua características de Big Data a partir da coleta e armazenamento de dados disponíveis na Web 2.0.
1.2.2 Objetivos Específicos:
- identificar ferramentas computacionais para apoiar a implementação da abordagem orientada a documento;
- formular um experimento baseado em análise de dados da Web 2.0;
- modelar o cenário do experimento utilizando técnica orientada a documento; - desenvolver um protótipo para a coleta, armazenamento e análise de dados não estruturados a fim de apresentar uma interface para visualização de informações quantitativas resultantes de sua análise;
- documentar os resultados e constatações obtidas.
JUSTIFICATIVA 1.3
Para suprir a alta demanda de armazenamento com velocidade, surgiram os bancos de dados não relacionais, caracterizados por escalarem horizontalmente, ou seja, sem a necessidade de investimento em máquinas extremamente poderosas, a medida que o volume de dados aumenta, aumenta o número de servidores, que podem ou não ser de alto desempenho. (NANCE, 2013).
As redes sociais são um importante canal de comunicação das organizações com os seus clientes e consumidores. Cada vez mais essas informações são coletadas e utilizadas para o processo de apoio à decisão.
Devido à grande quantidade de informação produzida por computadores e dispositivos móveis, os meios tradicionais de armazenamento e modelagem de dados não estão atendendo as consultas de maneira efetiva.
Novas formas de organização dos dados em Sistemas Gerenciadores de Banco de Dados (SGBDS) são apresentados como possíveis respostas à falta de agilidade na consulta e gestão dessa massa de dados produzida, como, por exemplo, os bancos de dados orientados a grafos e os banco de dados orientados a documento.
Neste trabalho, procura-se utilizar um banco orientado a documento, para facilitar a análise de dados coletados de recursos da Web 2.0.
A seção, a seguir, descreve de como o trabalho está organizado e que conteúdos são contemplados em cada capítulo.
ESTRUTURA DA MONOGRAFIA 1.4
Este trabalho está organizado em seis capítulos. O presente capítulo tem como objetivo apresentar os elementos introdutórios da pesquisa. O capítulo 2 apresenta os principais temas e assuntos na forma de um referencial teórico, a fim de, apoiar a execução do presente trabalho. No capítulo três, são apresentados os elementos relacionados com o método de pesquisa adotado. O capítulo 4 apresenta a modelagem proposta para o protótipo de solução. No capítulo cinco, são apresentados mais detalhes sobre o protótipo desenvolvido e avaliação do mesmo. No capítulo seis, último capítulo desse projeto, é apresentada a conclusão e os trabalhos futuros.
2 REFERENCIAL BIBLIOGRÁFICO
O presente capítulo descreve alguns elementos necessários para o entendimento deste trabalho. São abordados, primeiramente, conceitos básicos relacionados à modelagem de dados e são apresentados alguns modelos de modelagem de dados: relacional, dimensional e NoSQL. Em seguida, são abordadas informações relevantes sobre banco de dados orientado a documentos. Posteriormente, são apresentados conceitos relacionados a Web 2.0. Para concluir, é abordado o conceito de Big Data e suas principais características.
MODELAGEM DE DADOS 2.1
Churcher (2012) afirma que o modelo de dados é uma descrição precisa dos dados armazenados para um problema no mundo real, mas que o modelo de dados não é completo e nem uma descrição exata da situação real, ele será sempre baseado em definições e suposições, e possui um escopo limitado. É crucial que essas definições e suposições sejam claramente expressadas para que o cliente e o analista não falem com objetivos opostos.
A principal função de um modelo de dados é ajudar a entender as complexidades do ambiente do mundo real. Dentro do ambiente de banco de dados, um modelo de dados representa as estruturas de dados e suas características, relações, restrições, transformações e outras construções com o propósito de dar suporte a um domínio de problema específico. (CORONEL; MORRIS; ROB, 2009).
A modelagem de dados é o primeiro passo no projeto do banco de dados. Ela fornece a ligação entre as necessidades do usuário e a solução de software que o atende. (MULLER, 1999).
2.1.1 Relacional
O modelo relacional foi introduzido em 1970 por E.F Codd, da IBM, e representou um grande avanço para ambos os usuários e projetistas, sua simplicidade conceitual preparou o palco para uma verdadeira revolução de banco de dados. Em 1970, o trabalho de Codd foi considerado ingênuo e impraticável, os computadores daquela época não possuíam poder para implementar um modelo relacional, felizmente, o poder computacional cresceu exponencialmente assim como a eficiência dos sistemas operacionais. Ainda melhor, seu preço diminuiu rapidamente enquanto seu poder cresceu, permitindo que hoje, até mesmo computadores que custam uma fração do que custavam seus ancestrais, sejam capazes de rodar sofisticados bancos de dados relacionais. (CORONEL; MORRIS; ROB, 2009).
Codd propôs que os sistemas de banco de dados deveriam apresentar ao usuário uma visão de dados organizados como tabelas, chamados relações. Por trás dos panos, pode existir uma complexa estrutura de dados, permitindo uma resposta rápida a uma variedade de consultas. Ao contrário dos bancos de dados anteriores, o usuário do sistema relacional não se preocuparia com a estrutura de armazenamento, consultas poderiam ser expressas em uma linguagem de alto nível, o que aumentaria muito a eficiência dos programadores de banco de dados. (ULLMAN; WIDOM, 1997).
Silberschatz, Korth e Sudarshan (2010) afirmam que o modelo relacional é hoje o principal modelo de dados para aplicações comerciais de processamento de dados, alcançando essa primeira posição por sua simplicidade, facilitando o trabalho do programador comparado aos modelos de dados anteriores, como o modelo de redes e o modelo hierárquico.
Segundo Date (2004), o modelo relacional trata apenas de questões lógicas, não de questões físicas, e está relacionado com três aspectos principais dos dados: a estrutura de dados, a integridade de dados e a manipulação de dados.
No modelo relacional, um banco de dados é uma coleção de uma ou mais relações, em que cada relação é uma tabela com linhas e colunas. Essa simples representação tabular permite que até usuários iniciantes entendam o conteúdo do banco de dados, permitindo o uso de uma linguagem simples de alto nível para consulta de dados. (RAMAKRISHNAN; GEHRKE, 2000).
A principal construção para representar dados no modelo relacional é a relação. Uma relação consiste de um esquema e uma instância. A instância é uma tabela e o esquema descreve os cabeçalhos das colunas da tabela. (RAMAKRISHNAN; GEHRKE, 2000).
Segundo Elmasri e Navathe (2011), na terminologia formal do modelo relacional, uma linha é chamada de tupla, e um cabeçalho da coluna é chamado de atributo e a tabela é chamada de relação. O tipo de dado que descreve os tipos de valores que podem aparecer para cada coluna é representado por um domínio de valores possíveis.
O modelo relacional requer que cada componente de cada tupla seja atômico, ou seja, precisa ser de algum tipo elementar como os inteiros ou strings. Os componentes de qualquer tupla da relação precisa ter, em cada componente, um valor que pertença ao domínio da coluna correspondente (ULLMAN; WIDOM, 1997).
A descrição do banco de dados é chamada de esquema, é especificado durante o projeto do banco de dados, normalmente sofre pouca alteração. Já, uma instância são os dados em um determinado momento, que estão armazenados no banco de dados, estes podem sofrer alteração com muita frequência. (ELMASRI; NAVATHE, 2011).
O conceito de relação em uma analogia com a linguagem de programação corresponde a uma variável, enquanto no conceito de esquema corresponde a definição do tipo. Em geral, o esquema consiste em uma lista de atributos e seus domínios correspondentes. O conceito de instância corresponde na linguagem de programação como sendo o valor da variável. O valor de uma variável pode mudar, assim como o conteúdo de uma instância pode mudar, conforme a relação é atualizada. (SILBERSCHATZ; KORTH; SUDARSHAN, 2010).
Segundo Ramakrishnan e Gehrke (2000), entidade é um objeto do mundo real que pode ser diferenciado dos outros objetos, ou seja, cada entidade é única e distinta. Uma entidade é descrita, usando um conjunto de atributos, que dentre eles, deve existir ao menos uma chave que possua um valor único. Uma entidade pode possuir mais de uma chave com valor único, nesse caso, uma delas é definida como chave primária. Esta chave de valor único permite que as entidades possam ser unicamente identificadas em um conjunto de entidades.
Ainda, de acordo com Ramakrishnan e Gehrke (2000), relacionamento é uma associação entre duas ou mais entidades, e assim como as entidades, vários relacionamentos similares podem ser reunidos em um conjunto de relacionamentos.
Silberschatz, Korth e Sudarshan (2010) afirmam que o modelo relacional e o modelo ER (Entidade-Relacionamento) empregam princípios similares de design, permitindo que o modelo relacional possa ser expresso graficamente através do diagrama ER.
O Modelo ER foi introduzido em 1976 por Peter Chan, a representação gráfica de entidades e seus relacionamentos em uma estrutura de banco de dados se popularizaram rapidamente por complementar os conceitos do modelo relacional. Apesar de o modelo relacional ter sido um grande avanço sobre os modelos hierárquicos e de rede, ele ainda devia em recursos que o tornassem em uma ferramenta efetiva de banco de dados. (CORONEL; MORRIS; ROB, 2009).
2.1.2 Dimensional
Um dos bens mais importantes de qualquer organização é a informação, que na maioria das vezes, é utilizada com a finalidade de manter o registro das operações e servir de apoio a tomada de decisões. Simplificando, os sistemas operacionais são onde a informação entra e o sistema DW/BI é onde a informação sai. Os sistemas operacionais são otimizados para processar transações com eficiência, e quase sempre podem lidar com apenas um registro de transação por vez. Devido a sua finalidade, estes sistemas normalmente não mantem um histórico dos dados, ao invés disso, atualiza-os com mais frequência para o estado mais atual. (KIMBALL; ROSS, 2013).
Um data warehouse (DW) é um grande repositório de dados históricos que podem ser utilizados no apoio à decisão. Seu funcionamento é diferente dos sistemas operacionais, que contém os dados necessários para as operações diárias da organização. Esses dados operacionais tendem a mudar rapidamente e com grande frequência, as tabelas desses sistemas são mantidas em um tamanho pequeno e gerenciável, tendo seus dados antigos periodicamente eliminados. Ao contrário, o data warehouse recebe dados históricos periodicamente, com seu tamanho, podendo chegar a centenas de gigabytes ou até mesmo petabytes. (TEOREY et. al, 2011).
Kimball (1998) afirma que a modelagem dimensional é uma técnica de projeto lógico que busca apresentar o dado em uma estrutura padrão que seja intuitiva e permita uma alta performance de acesso. Todo modelo dimensional é composto por uma tabela de fatos e um conjunto de tabelas menores chamadas de tabelas de dimensão.
Ainda, segundo Kimball (1998), cada tabela de dimensão possui uma única chave primária que fará parte da formação da chave composta da tabela de fatos.
Os esquemas dimensionais mais comuns são os de estrela e o floco de neves, o esquema de estrela é apresentado por uma tabela de fatos com uma única tabela para cada dimensão, já, o esquema floco de neve, é uma variação do esquema de estrela, em que as tabelas de dimensão podem ter suas próprias tabelas de dimensão, formando uma hierarquia ao normalizá-las. (ELMASRI; NAVATHE, 2011).
2.1.3 NoSQL
Segundo Strauch (2011), O termo NoSQL foi usado pela primeira vez em 1998 para um banco de dados relacional que omitiu o uso de SQL, e foi novamente utilizado somente em 2009 em uma conferência em São Francisco organizada por defensores dos bancos de dados Não-Relacionais.
O crescimento exponencial de dados, embalado pelos avanços tecnológicos que permitem uma fácil e constante interação das pessoas tanto pela tecnologia web quanto a móvel, resultou na necessidade do uso de bancos de dados especializados. Nos últimos anos, uma nova geração de banco de dados vem se disseminando, crescendo em uso e em sofisticação, atualmente, esse novo tipo de banco de dados é conhecido como banco de dados NoSQL. O termo NoSQL, que significa “Not only SQL” ou “Não apenas SQL” em português, é normalmente para descrever um novo tipo de SGBD (Sistemas Gerenciador de Banco de Dados) que não é baseado no tradicional modelo de banco de dados relacional. (CORONEL; MORRIS; ROB, 2009).
Os bancos de dados NoSQL podem ser utilizados em aplicações que possuem um grande volume de transações necessitam de baixa latência no acesso à grande quantidade de dados e demandam de alta disponibilidade do serviço. As organizações que utilizam os bancos de dados relacionais começaram a aplicar diversas técnicas para melhorar o desempenho, mas não resolveram as principais limitações dos bancos de dados relacionais, adicionando ainda mais custos.
Ao contrário dos sistemas gerenciadores de bancos de dados relacionais, a maioria dos bancos de dados NoSQL são projetados para escalarem bem horizontalmente e não dependerem de alta disponibilidade de hardware. Máquinas podem ser adicionadas,
removidas e até mesmo falharem sem precisar do mesmo esforço que seria necessário ao escalar um banco de dados relacional. (STRAUCH, 2011).
Tiwari (2011) afirma que escalabilidade é a habilidade de um sistema em aumentar seu rendimento com a adição de recursos para lidar com o aumento de carga. A escalabilidade pode ser alcançada ou dispondo de uma máquina robusta e poderosa para suprir as demandas adicionais, ou contando com um aglomerado de máquinas inferiores trabalhando como uma unidade. A prática de utilização de máquinas robustas e poderosas com grande capacidade de processamento e armazenamento é comumente classificada de escalabilidade vertical, que pode ser caracterizado também por seu alto custo. Já, a escalabilidade horizontal envolve a adição de máquinas menos poderosas e mais baratas para trabalharem em conjunto conforme a carga do sistema aumenta.
Segundo Sadalage e Fowler (2012), os bancos de dados relacionais não estão sumindo, eles continuarão sendo o banco de dados mais utilizados, a mudança é que agora nós podemos ver os bancos de dados relacionais como mais uma opção de armazenamento. Nós precisamos entender a natureza dos dados que estamos armazenando e como queremos manipulá-los. Essa visão gerou o termo Persistência Poliglota, que se refere ao fato da possibilidade das organizações escolherem a melhor tecnologia de armazenamentos para diferentes circunstâncias.
Os bancos de dados relacionais assumem uma estrutura de dados bem definida e tem como pré-requisito que as propriedades dos dados sejam especificadas antecipadamente. Esses tipos bancos de dados podem lidar com um pouco de irregularidade, mas, no contexto de grande quantidade de dados pouco estruturados, eles são obrigados a se adaptar. Desnormalizar as tabelas, eliminar as restrições e abrir mão das garantias advindas do controle de transações podem ajudar no escalonamento, mas começa a tornar o banco de dados semelhante a um produto NoSQL. (TIWARI, 2011).
Ainda, segundo Tiwari (2011), há um preço pela flexibilidade dos bancos de dados NoSQL, ao aliviar os problemas impostos pelos banco relacionais e facilitar o trabalho com grande quantidade de dados desordenados, tira também o poder da integridade transacional, das consultas e da indexação flexível.
Segundo Coronel, Morris e Rob (2009, tradução nossa, p. 416), “Uma transação é uma unidade lógica de trabalho que precisa ser totalmente concluída ou totalmente abortada; nenhum resultado diferente é aceitável”.
Todas as instruções SQL em uma transação precisam ser completadas com sucesso ao satisfazer todas as restrições de integridade dos dados, caso contrário, toda a
transação é revertida para o estado original do banco de dados antes de a transação ter sido iniciada, o que garante que o banco de dados esteja sempre em um estado consistente. (CORONEL; MORRIS; ROB, 2009).
Segundo McCreary e Kelly (2014), o controle de transações é importante em ambientes de computação distribuída, no que diz respeito ao desempenho e consistência. Usa-se normalmente um dentre os dois modelos de controle de transação: ACID, para os bancos de dados relacionais e BASE para os sistemas NoSQL. Ambos os sistemas relacionais e não relacionais são capazes de criar tais controles, o que os difere, é o esforço necessário pelos desenvolvedores da aplicação e o nível de controle dessas transações.
O acrônimo ACID (Atomicidade, Consistência, Isolamento e Durabilidade) teve início com Jim Gray, que inventou o processamento de transações na década de 70 e colocou em seu artigo clássico “The Transaction Concept: Virtues and Limitation”, em Junho de 1981 (CELKO, 2014).
Segundo Celko (2014), os termos do acrônimo ACID significam:
• atomicidade - Todas as tarefas de uma transação precisam ser realizadas, ou nenhuma é realizada. Neste princípio, se um elemento da transação falhar, a transação inteira falha;
• consistência - A transação precisa obedecer todas as regras definidas pelo sistema, e o banco de dados precisa estar em um estado consistente do início ao fim da transação;
• isolamento - Nenhuma transação possui acesso a qualquer outra transação existente, cada transação é independente, isso é necessário para o desempenho e consistência das transações no banco de dados;
• durabilidade - Uma vez completada, a transação não pode ser revertida, sobrevivendo a falhas no sistema, falta de energia e outros tipos de pane que podem ocorrer com o sistema.
Para McCreary e Kelly (2014), enquanto o foco dos sistemas ACID é a alta integridade dos dados, os sistemas NoSQL que utilizam BASE priorizam a alta disponibilidade. O acrônimo BASE tem origem dos termos Disponibilidade básica, estado leve e consistência eventual (Basically available, Soft state, Eventual consistency) que significam:
• basically available - Permite que os sistemas sejam temporariamente inconsistentes, assim as transações são gerenciáveis;
• soft state - Reconhece que infidelidade dos dados é temporariamente permitida e os dados podem ser alterados enquanto estiverem sendo utilizadas, reduzindo assim a quantidade de recursos utilizados;
• eventual consistency - Significa que eventualmente, quando toda a lógica tiver sido executada, o sistema é deixado em um estado consistente.
Um dos desafios enfrentados pelos usuários de sistemas NoSQL, é a existência de diversos padrões de arquitetura disponíveis para utilização. (MCCREARY; KELLY, 2014). Para o presente trabalho, foi escolhido o banco de dados orientado a documento.
BANCO DE DADOS ORIENTADO A DOCUMENTO 2.2
Segundo Harrison (2010), em meados da década de 80, Mitch Kapor, fundador da Lotus e o arquiteto-chefe de software da Microsoft até 2010, e Ray Ozzie trabalharam juntos para criar o Lotus Note, ferramenta de colaboração e produtividade pessoal comumente vista como uma alternativa aos recursos de e-mail e agendamento disponíveis no Microsoft Outlook. Apesar de ser raramente visto como uma plataforma de banco de dados, o Lotus Note incluía um banco de dados interno, otimizado para armazenar e trabalhar com documentos complexos, inspirando a abordagem tomada por dois dos sistemas gerenciadores de bancos de dados mais conhecidos, CouchDB e MongoDB, que, assim como o Lotus Note, estes bancos não armazenam os dados em tabelas relacionais normalizadas, mas em uma rica estrutura auto descritiva.
Ritchie (2013) afirma que os bancos de dados de documentos são constituídos de estrutura de dados semiestruturados, livre de esquema, conhecidos como documentos, que, neste caso, se refere a uma estrutura de dados rica que pode representar desde dados simples a complexos. Um documento pode conter qualquer quantidade de campos de qualquer tamanho, e são tipicamente representados em notação de objeto JavaScript (JSON).
Tiwari (2011) ressalta que os bancos de dados de documentos não são bancos com documentos nem sistemas gerenciadores de conteúdo, uma confusão comum que ocorre com desenvolvedores que estão iniciando o estudo sobre o assunto. A palavra documento em banco de dados orientado a documento se refere a um conjunto de dados semiestruturados
compostos por pares de chave-valor em documentos tipicamente no formato JSON, e não planilhas ou documentos comuns.
Segundo Hecht e Jablonski (2011), as chaves dos pares chave-valor, que estruturam o documento no banco de dados orientado a documento, precisam ser únicas. Todo documento possui uma chave especial “ID”, que também é única em uma coleção de documentos, dessa forma é possível identificar o documento explicitamente. Diferentemente dos bancos de dados chave-valor (key-value), em que somente é possível efetuar a consulta pela chave, no banco orientado a documento a consulta pode ser feita também pelo valor.
O principal conceito em um banco de dados de documento é o documento. O banco de dados armazena e recupera documentos que podem ser no formato XML, JSON, BSON, entre outros. Estes documentos são auto descritivos, uma estrutura de dados hierárquica em forma de árvore que pode ser composto por mapas, coleções e valores escalares. (SADALAGE; FOWLER, 2012).
Pichiliani (2013) destaca que um dos principais pontos que difere os tradicionais bancos de dados relacionais com os bancos de dados orientado a documento é a rigidez do modelo. Se, por exemplo, uma entidade possuir 10 atributos, espera-se que cada um deles receba um valor para cada registro da entidade, caso contrário, haverá um erro indicando uma violação de integridade da entidade. Ao contrário nos bancos de dados orientados a documento, essa rigidez não existe, é possível criar uma coleção de documentos que terá seus atributos definidos de acordo com os dados, tornando o modelo flexível.
A Figura 1 representa um documento que pode ser considerado uma linha em um banco de dados relacional.
Figura 1 - Exemplo de documento
Fonte: Sadalage e Fowler, 2012.
É possível observar que Figura 2 é similar a Figura 1, mas possuem diferenças em seus atributos.
Figura 2 – Exemplo de documento semelhante
Fonte: Sadalage e Fowler, 2012.
Segundo Sadalage e Fowler (2012), o esquema de dados pode diferir entre os documentos e ainda assim pertencerem à mesma coleção, ao contrário dos bancos de dados relacionais em que cada linha da tabela precisa seguir o mesmo esquema. Na Figura 2, pode-se obpode-servar que a lista de citiesvisited foi reprepode-sentada como um array, e a lista de adrespode-ses foram representados como uma lista de documentos embutidos no documento principal.
Tiwari (2011) afirma que os bancos de dados de documento tratam o documento como um todo, permitindo reunir um conjunto diversificado de documentos em uma única coleção. Os bancos de dados de documentos permitem a indexação de documentos com base no seu identificador primário e, também, em suas propriedades.
Ainda, segundo Tiwari (2011), atualmente existem alguns diferentes bancos de dados de documentos de código livre disponíveis, mas, dentre eles, os que mais se destacam são o MongoDB e o CouchDB.
Segundo Lerman (2011), com exceção de algumas variações, o acesso aos dados nesses bancos de dados são feitos normalmente via protocolo HTTP, armazenam seus dados como documentos em formato JSON e dispõem de uma API para diversas linguagens.
A Figura 3 apresenta uma relação de alguns bancos de dados NoSQL e seus respectivos protocolos de acesso aos dados.
Figura 3 - Relação de Bancos de Dados e seus protocolos de acesso correspondentes
Fonte: Vaish, 2013.
A Figura 4 demonstra uma representação do relacionamento no modelo tradicional e o orientado a documento, em que as entidades da direita estão no formato embutido como um documento JSON, utilizado pelos bancos orientados a documento. É possível observar também que nas entidades (documentos) da direita, apesar de possuírem características diferentes em alguns atributos, todos os documentos pertencem à mesma coleção.
Figura 4 - Exemplo de relacionamento embutido no formato JSON
Fonte: Pichiliani, 2013.
Harrison (2010) comenta que os bancos de dados de documentos atraem os desenvolvedores pelas semelhanças do seu modelo de dados com o modelo orientado a objetos das linguagens mais modernas, o esforço necessário para a tradução dos objetos dificulta a produtividade do programador. Em um banco de dados de documentos, o documento é mapeado quase que diretamente para a estrutura de classe da linguagem de programação, tornando a programação muito mais fácil.
WEB 2.0 2.3
O conceito de “Web 2.0” surgiu em 2004 durante uma conferencia de brainstorming entre a editora O´Reilly e a MediaLive International em que foi observado que a web estava mais importante do que nunca com o surgimento regular de novos sites e
aplicações. No ano seguinte, o termo contabilizava mais de 9.5 milhões citações no Google. (O’RELLY, 2005).
Segundo Cormode e Krishnamurthy (2008), o termo "Web 2.0" captura uma combinação de inovações na Web nos últimos anos. Não existe uma definição precisa para o termo Web 2.0 e muitos sites são difíceis de rotulá-los em "Web 1.0" ou "Web 2.0", mas existe uma clara diferenciação entre os sites Web 2.0 mais populares como Facebook e YouTube com os "antigos" , essa diferenças ficam visíveis, quando analisamos uma série de fatores como o tecnológico (programação e tecnologias visuais que permitem interação do usuário), estrutural (propósito e layout do site) e sociológico (noção de amigos e grupos).
Para Anderson (2007), é importante compreender que a "Web 2.0" não deve ser vista como algo oposto a "Web 1.0", mas, sim, como uma consequência de uma implementação mais completa da Web. Essa distinção é a chave para o entendimento de onde estão os limites entre a "Web" como um conjunto de tecnologias, e a "Web 2.0", na tentativa de conceituar o significado dos resultados habilitados por essas tecnologias Web.
Em seu famoso artigo, Tim O'Reilly define uma série de princípios quem tem como propósito classificar o que pode ser compreendido como "Web 2.0". Tal classificação tornou-se uma demanda urgente devido ao termo "Web 2.0" ter sido amplamente difundido e utilizado pelas empresas como um jogo de marketing sem possuir um real entendimento do seu significado. Tim destaca o Aproveitamento da Inteligência Coletiva como sendo princípio por trás do sucesso das grandes empresas nascidas na era da Web 1.0 e sobreviveram para liderar a era da Web 2.0. (O’RELLY, 2005). Empresas como eBay e Amazon são casos de sucesso na utilização deste princípio, enquanto o eBay tem como produto a própria interação do usuário, a Amazon utiliza o engajamento do usuário na melhora dos seus serviços como resultados de busca mais precisas e, consequentemente, o aumento de suas vendas.
De acordo com Vossen e Hagemann (2007), é preciso distinguir os conceitos entre Web 2.0 e Redes Sociais. A Web 2.0 é tanto uma plataforma onde novas tecnologias têm sido criadas, quanto um espaço onde o usuário pode ser o ator principal. O Facebook, por exemplo, foi feito utilizando tecnologias da Web 2.0 como requisições AJAX e o comentário dos usuários. Os participantes em todas as redes sociais como esta são tão importantes quanto o conteúdo que enviam e compartilham com os outros.
Ainda, segundo Vossen e Hagemann (2007), a principal diferença entre a Web 1.0 e a Web 2.0, é que diferente da Web 1.0, na Web 2.0 qualquer usuário pode ser um produtor de conteúdo e constantemente novas tecnologias vêm sendo desenvolvidas com o intuito de
maximizar essa produção de conteúdo. Como resultado do aumento na utilização dos recursos da Web 2.0, pode ser percebido um grande impacto no tráfego de dados na Internet.
BIG DATA 2.4
Assim como o termo cloud computing, podemos passar semanas em busca de uma definição perfeita para Big Data que será em vão, não existe tal definição. Todo vendedor de tecnologia ou consultor de TI tentará se autopromover, com esse fim, muitas empresas e líderes inventaram sua própria definição de Big Data. Douglas Laney (então do Grupo Meta, e atualmente com Gartner) fez sua primeira tentativa em 2001 ao escrever sobre o crescimento dos desafios e oportunidades em torno das organizações em relação ao crescente volume de dados. (SIMON, 2013).
Taurion (2013) afirma que, diante da revolução, existe a possibilidade de análise de uma quantidade de dados nunca vista antes, fenômeno chamado de Big Data, que tem um impacto tão grande quanto à popularização da internet no que diz respeito aos processos de negócio e decisão. Devido à ineficácia dos sistemas transacionais, a grande maioria dos dados que circulam pela empresa são invisíveis e não têm sido utilizados nos processos ou tomadas de decisão. Nesse sentido, Big Data pode ser comparado a um microscópio, em alusão a sua eficiência no processamento de grande quantidade de dados da empresa.
Para simplificar o termo Big Data, é normalmente definido usando quatro Vs; volume, variedade, velocidade, e veracidade. A característica de veracidade foi adicionada recentemente em resposta aos problemas de qualidade e origem que alguns clientes começaram a ter com suas soluções em Big Data. Alguns analistas incluem ainda outras características baseadas em V como variabilidade e visibilidade. (CORRIGAN et al., 2013).
Segundo Simon (2013), Douglas Laney definiu, anos antes da popularização do termo Big Data, três dimensões primárias (volume, variedade e velocidade) para caracterizar esse grande dilúvio de dados. Seus três V´s emperraram e, atualmente, a maioria das pessoas familiarizadas com Big Data já ouviram falar sobre volume, variedade e velocidade.
3 MÉTODO
Segundo Marconi e Lakatos (2003), o método é “o conjunto de atividades sistemáticas e racionais que, com maior segurança e economia, permite alcançar o objetivo - conhecimentos válidos e verdadeiros -, traçando o caminho a ser seguido, detectando erros e auxiliando as decisões do cientista”.
No presente capítulo, define-se o tipo de pesquisa do trabalho proposto, a lista das etapas metodológicas que devem ser concluídas para se chegar ao objetivo do trabalho. Em seguida, apresenta-se o desenho da solução e, por fim, as delimitações do trabalho.
CARACTERIZAÇÃO DO TIPO DE PESQUISA 3.1
Segundo Gil (2002), a pesquisa pode ser definida como “procedimento racional e sistemático que tem como objetivo proporcionar respostas aos problemas que são propostos”. O autor também afirma que a pesquisa se faz necessária quando não se dispõem de informações suficientes para solucionar o problema, ou a desorganização das informações disponíveis é muito grande para ser relacionada ao problema.
Ander-Egg (1978, apud MARCONI; LAKATOS, 2003, p.155) afirma que a pesquisa é um “procedimento reflexivo sistemático, controlado e crítico, que permite descobrir novos fatos ou dados, relações ou leis, em qualquer campo do conhecimento”.
O presente trabalho é classificado como pesquisa aplicada com uma abordagem qualitativa do problema. De acordo com Silva e Menezes (2005), a pesquisa aplicada “objetiva gerar conhecimentos para aplicação prática e dirigir à solução de problemas específicos. Envolve verdades e interesses locais.”.
Segundo Godoy (1995, p. 62-63), a pesquisa qualitativa “tem o ambiente natural como fonte direta de dados, e o pesquisador como instrumento fundamental”. Ainda, segundo o autor, a preocupação fundamental nos estudos denominados qualitativos é a análise do mundo empírico em seu ambiente natural, e a preocupação dos pesquisadores qualitativos é o processo e não com os resultados do produto.
Do ponto de vista dos procedimentos técnicos, este trabalho é caracterizado como uma pesquisa bibliográfica, por ser desenvolvida com base em livros e artigos científicos já existentes (SILVA; MENEZES, 2005; GIL, 2002).
ETAPAS METODOLÓGICAS 3.2
O processo de pesquisa e elaboração deste trabalho organiza-se de acordo com as seguintes etapas:
1) Definição do Problema;
2) Definição da Proposta de Solução; 3) Definição do Experimento;
4) Revisão Bibliográfica;
5) Modelagem da Base de Dados; 6) Implementação do Protótipo; 7) Execução do Experimento;
8) Documentação e Constatações dos Resultados; 9) Considerações Finais.
Figura 5 - Etapas
Fonte: O Autor (2014).
A Figura 5 apresenta o fluxo do processo de pesquisa e desenvolvimento do trabalho, de acordo a uma representação gráfica das etapas listadas anteriormente.
DESENHO DA SOLUÇÃO 3.3
O modelo de solução apresentado consiste no desenvolvimento de um protótipo de extração e análise de informações provenientes de alguma fonte de dados que se enquadre nos conceitos de Web 2.0. Considerando os objetivos propostos e o caso de uso, a solução utiliza de um banco de dados orientado a documento.
O sistema gerenciador de banco de dados utilizado foi o MongoDB, aplicação de código aberto e orientado a documento.
Figura 6 - Desenho da Solução
Fonte: O Autor (2014).
A Figura 6 apresenta uma visão geral da solução proposta, demonstrando as ferramentas utilizadas, a origem sugerida de dados sugerida para extração e o banco de dados proposto para o armazenamento e análise das informações.
DELIMITAÇÕES 3.4
Caracterizando o tipo de pesquisa apresentado, não foram feitos testes de benchmark ou qualquer análise com fins estatísticos no protótipo desenvolvido.
O SGBD utilizado para o banco orientado a documentos é o MongoDB, por ser um banco de dados muito popular e de código aberto, possuir uma boa documentação e uma grande comunidade ativa para suporte ao aprendizado e à busca de soluções.
Não se tem como objetivo fazer uma análise comparativa entre as ferramentas disponíveis como banco orientado a documentos, pois esse não se trata do foco do trabalho.
O trabalho não se propõe a fazer qualquer tipo de comparativo com bancos tradicionais como modelagens relacional ou dimensional, busca se apenas estudar a forma de se modelar orientado a documento.
4 MODELAGEM
Este capítulo apresenta as definições de técnica e metodologia e alguns conceitos básicos como UML e seus principais diagramas, o cenário de aplicação, descrevendo o contexto em que é baseada a modelagem da solução. Ainda, neste capítulo, é feito levantamento de requisitos, assim como casos de uso, modelo de domínio, modelo E.R e o modelo orientado a documento.
UML 4.1
Até metade da década de 1990, surgiram várias propostas técnicas para modelagem de sistemas no paradigma de orientação a objetos. Tornou-se comum duas propostas técnicas apresentarem diferentes notações gráficas para modelar uma mesma perspectiva, em que cada técnica possuía pontos fortes e fracos, percebendo-se assim a necessidade de uma linguagem padrão para modelagem de sistemas que fosse amplamente aceita pela indústria e ambiente acadêmico (BEZERRA, 2007).
Segundo Rumbaugh, Jacobson e Booch (2005), a UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é uma linguagem padrão para escrita de diagramas de software que pode ser utilizada para visualizar, especificar, construir e documentar os artefatos de um sistema complexo.
De acordo com Guedes (2008), a UML surgiu da união de três métodos de
modelagem: o método de Booch, OMT (Object Modeling Technique) de Jacobson, e o
método OOSE (Object-Oriented Software Engineering) de Rumbaugh. Inicialmente, com a união do método de Booch e o OMT de Jacobson, resultou o lançamento do Método Unificado no final de 1995. Rumbaugh juntou-se, logo em seguida, a Booch e Jacobson, tendo seu método OOSE incorporado à nova metodologia. Popularmente conhecidos como “Os Três amigos”, Booch, Jacobson e Rumbaugh tiverem como resultado de seu trabalho o lançamento da primeira versão da UML propriamente dita, em 1996.
A UML foi aprovada como padrão, em 1997, pela OMG (Object Management Group), e, desde então, tem tido uma grande aceitação pela comunidade de desenvolvedores
de sistemas. A OMG é um consórcio internacional que define e ratifica padrões na área da orientação a objetos. (BEZERRA, 2007).
Para Fowler (2005), “UML é uma família de notações gráficas, apoiada por um metamodelo único, que ajuda na descrição e no projeto de sistemas de software, particularmente daqueles construídos, utilizando o estilo orientado a objetos (OO)”.
De acordo com Guedes (2008), UML é uma linguagem visual para modelagem de sistemas no paradigma de Orientação a Objetos, adotada, nos últimos anos, como uma linguagem padrão de modelagem de software na indústria de Engenharia de Software.
Ainda, segundo Guedes (2008, p.18):
UML não é uma linguagem de programação, e sim uma linguagem de modelagem, cujo objetivo é auxiliar os engenheiros de software a definirem as características do software, tais como seus requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus processos e inclusive suas necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado.
Segundo Bell (2003), a UML dispõe diversos tipos de diagramas, que, quando utilizados com uma metodologia, facilita o entendimento da aplicação em desenvolvimento. Os diagramas padrão da UML mais úteis são: diagrama de caso de uso, diagrama de classes, diagrama de sequência, diagrama de estados, diagrama de atividades, diagrama de componentes, e diagrama de implantação.
• Diagrama de Caso de Uso corresponde a uma visão externa do sistema e representa graficamente os atores, casos de uso e os relacionamentos entre eles (BEZERRA, 2007).
• Diagrama de Classes, para Fowler (2005), é “Um diagrama de classes descreve os tipos de objetos presentes no sistema e os vários tipos de relacionamentos estáticos existentes entre eles”.
• Diagrama de Sequência preocupa-se com a ordem temporal em que as mensagens são trocadas entre os objetos envolvidos em um determinado processo (GUEDES, 2008).
• Diagrama de Estados para, Bezerra (2007), “permite descrever o ciclo de vida de objetos de uma classe, os eventos que causaram a transição de um estado para outro e a realização de operações resultante”.
• Diagrama de Atividades são um dos cinco diagramas da UML para a modelagem dos aspectos dinâmicos dos sistemas, um Diagrama de
Atividade é basicamente um fluxograma que demonstra o fluxo de controle de cada atividade (RUMBAUGH, JACOBSON E BOOCH, 2005).
• Diagrama de Componentes são diagramas estruturais que mostram as interfaces externas e a composição interna de um componente (RUMBAUGH, JACOBSON E BOOCH, 2005).
• Diagrama de Implantação determina as necessidades de hardware assim como todo o aparato físico sobre o qual o sistema deverá ser executado (GUEDES, 2008).
Com base nos conceitos e diagramas apresentados nessa seção, é definido um método para a modelagem.
MÉTODO DEFINIDO PARA MODELAGEM 4.2
Nesta seção, são apresentados, em um fluxograma, os diagramas selecionados e sua sequência de desenvolvimento ,e posteriormente, uma breve descrição das particularidades de cada diagrama que a levaram a sua escolha.
Figura 7 - Fluxograma de Modelagem
Fonte: O Autor (2014).
MODELAGEM PROPOSTA 4.3
Nesta seção, é apresentada uma descrição do cenário de aplicação em que está relacionada a modelagem da solução, a listagem dos requisitos funcionais e não funcionais, casos de uso, assim como os modelos de domínio, E.R e, por fim, o modelo orientado a documento.
4.3.1 Cenário de aplicação
O cenário de aplicação consiste no desenvolvimento de um sistema que armazena e disponibiliza para visualização os dados extraídos de uma fonte de dados enquadrado no conceito de Web 2.0. Para este trabalho, a fonte de dados, em questão, é a rede social Twitter, um caso clássico de serviço que pode ser enquadrado nos conceitos de Web 2.0.
O sistema efetua consultas periódicas com uma determinada palavra-chave ao Twitter, utilizando a API de comunicação que disponibiliza, em que o resultado no formato JSON é armazenado no banco de dados do sistema desenvolvido. Os dados utilizados do resultado da consulta serão basicamente o conteúdo de texto das mensagens, a hora da mensagem, o código do usuário e o nome do usuário. Os dados resultantes do Twitter não são estruturados, mas para fins de entendimento, o presente trabalho apresenta uma modelagem convencional.
Para representar uma solução de Big Data, é utilizada uma solução de banco de dados não relacional. A solução escolhida é o MongoDB, um banco de dados orientado a documentos que possui como características a alta performance e escalabilidade, além de trabalhar nativamente com os dados em formato JSON.
Por fim, o sistema apresenta uma interface em que podem ser visualizados os dados armazenados do Twitter, em que constantes requisições ao sistema desenvolvido são feitas, demonstrando o funcionamento de uma solução de Big Data em um ambiente Web 2.0.
4.3.2 Levantamento de Requisitos
Segundo Guedes (2008), levantamento de requisitos é umas das primeiras fases de engenharia de um software, em que o engenheiro de software busca compreender as necessidades do usuário assim como seu desejo quanto ao que o sistema deve realizar.
Para Sommerville (2007, p.80), os requisitos funcionais “São declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações ”.
Quadro 1 - Requisitos Funcionais
Identificador Descrição
RF01 O sistema deve permitir o cadastro de usuário
RF02 Cada usuário deve ser cadastrado com um único identificador
RF03 O sistema deve permitir o cadastro de conteúdo de texto
RF04 O sistema deve armazenar o conteúdo de texto relacionado com um usuário
RF05 O sistema deve permitir a carga de arquivos JSON para o banco de dados
RF06 O sistema deve permitir a visualização do conteúdo de texto cadastrado
Fonte: O Autor (2014).
O Quadro 1 ilustra os requisitos funcionais modelados com base nos dados provenientes da API do Twitter e que será armazenado pelo sistema desenvolvido.
De acordo com Bezerra (2007, p.21), “os requisitos não-funcionais declaram as características de qualidade que o sistema deve possuir e que estão relacionadas as suas funcionalidades”.
Quadro 2 - Requisitos Não Funcionais
Identificador Descrição
RNF01 O sistema deve permitir a integração com o banco de dados MongoDB
RNF02 O sistema deve manter sigilo sobre os dados dos usuários do Twitter obtidos
através da API REST do Twitter
RNF03 O sistema deve respeitar o rate limit de requisições ao Twitter
RNF04 O sistema deve ser simples, e visual, apenas para observação dos dados
armazenados Fonte: O Autor (2014).
O Quadro 2 ilustra os requisitos não funcionais do sistema desenvolvido.
4.3.3 Casos de Uso
Segundo Fowler (2005, p.104), “casos de uso são uma técnica para captar os requisitos funcionais de um sistema”.
Bezerra (2007, p.45) afirma que o modelo de caso de uso “é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com ele”. Ainda segundo Bezerra (2007), a modelagem através de casos de uso foi idealizada na década de 1970 por Ivar Jacobson, que mais tarde incorporou a técnica a um processo de desenvolvimento de software denominado Objectory. Anos depois, Jacobson se uniu a Booch e Rumbaugh, incorporando a notação de caso de uso a UML.
Figura 8 - Modelo de Caso de Uso
A Figura 8 representa o modelo de caso de uso definido para o sistema desenvolvido.
Figura 9 - Descrição dos Casos de Uso
Identificador Descrição
UC001 Permite o usuário efetuar seu cadastro no sistema inserindo suas
informações como nome completo e e-mail.
UC002 Permite que o usuário cadastre mensagens de texto de até 140
caracteres que será relacionada pelo sistema ao seu usuário através do código identificador único do usuário.
UC003 Permite o usuário visualizar o conteúdo de todas as mensagens
armazenadas pelo sistema. Fonte: O Autor (2014).
A Figura 9 ilustra a descrição dos casos de uso.
4.3.4 Modelo de Domínio
Um modelo de domínio é uma representação visual de classes conceituais ou objetos do mundo real em um domínio de problema. O modelo de domínio é também chamado de modelo conceitual, modelo de objeto de domínio e modelo de análise de objeto (LARMAN, 2004).
Segundo Rosenberg e Stephens (2007), o modelo de domínio é essencialmente um glossário do projeto, um dicionário de todos os termos utilizados no projeto. O que torna o modelo de domínio melhor que um glossário do projeto é que mostra graficamente como esses diferentes termos se relacionam uns com os outros, sendo, na prática, um diagrama de classes simplificado, com linhas desenhadas entre as diferentes classes, demonstrando como se relacionam.
Figura 10 - Modelo de Domínio
Fonte: O Autor (2014).
A Figura 10 ilustra o modelo de domínio, permitindo visualizar os dados do protótipo de uma maneira geral.
4.3.5 Modelo E.R
O modelo E.R foi apresentado primeiramente em 1976 por Peter Chen, sua forma utiliza de retângulos para especificar as entidades e objetos no formato de diamante para representar os vários tipos de relacionamento que são diferenciados por letras ou números colocados nas linhas que conectam os diamantes aos retângulos. (TEOREY et. al., 2011).
Figura 11 - Modelo E.R
Fonte: O Autor (2014).
A Figura 11 representa a modelagem entidade-relacionamento do protótipo desenvolvido.
4.3.6 Modelo Orientado a Documento
Uma estrutura de dados foi definida em um modelo orientado a documento que pode ser visualizada na Figura 12.
Figura 12 - Modelo Orientado a Documento
MENSAGEM
id_mensagem texto nome_usuario data tag
250075927172759552 Banco de dados orientado a documento
daniel Mon Sep 24 03:35:21 +0000 2012 NoSQL, MongoDB, DB, Documento, TCC
Fonte: O Autor (2014).
A Figura 12 representa o modelo orientado a documento do protótipo desenvolvido em formato de tabela para um fácil entendimento e visualização.
Figura 13 - Modelo Orientado a Documento
Fonte: O Autor (2014).
A Figura 13 ilustra um documento do MongoDB, um modelo orientado a documento no formato JSON e representa a mesma estrutura de dados apresentada na Figura 12.
5 DESENVOLVIMENTO
Este capítulo apresenta as tecnologias e ferramentas utilizadas no desenvolvimento da proposta de solução, assim, como o histórico de desenvolvimento no que diz respeito aos problemas e soluções encontradas no processo de desenvolvimento do experimento.
Na sequência é apresentado o experimento com uma representação gráfica da infraestrutura criada para conceber a proposta de solução, a descrição do cenário em que foi aplicado o experimento, a apresentação do protótipo desenvolvido e suas principais funcionalidades. E por fim, é descrito a avaliação da proposta e os resultados obtidos.
FERRAMENTAS TECNOLÓGICAS 5.1
Esta seção aborda as ferramentas e tecnologias utilizadas na concepção da proposta de solução e são brevemente descritas a seguir.
Figura 14 - Ferramentas Tecnológicas
A Figura 14 ilustra todas as ferramentas e tecnologias utilizadas no desenvolvimento do protótipo.
5.1.1 Apache HTTP Server
O Apache é um servidor web de código aberto que pode ser executado virtualmente em todos os sistemas operacionais disponíveis. É um projeto voltado a comunidade possuindo muitos desenvolvedores contribuindo para sua evolução. O fato de ser um projeto disponível sem qualquer custo provavelmente contribui para sua grande popularidade. (HANSEN; LENGSTORF, 2014).
Segundo o site Netcraft (2014), sua pesquisa realizada em outubro de 2014 foi respondida por mais de 1 bilhão de web sites, resultando com o servidor web Apache como o mais utilizado com uma taxa de 37.45% contra 33.58% do segundo colocado, o servidor IIS da Microsoft.
Assim como todos os servidores web, o servidor Apache aceita requisições HTTP e retorna uma resposta HTTP, toda a internet funciona em cima de servidores web e todos os web sites que visitamos demonstram essa funcionalidade. (HANSEN; LENGSTORF, 2014).
5.1.2 PHP
PHP (Hypertext Preprocessor) é uma linguagem de programação de código aberto muito popular que pode ser combinado com código HTML, adequada especialmente para os desenvolvedores web. Uma das principais vantagens do PHP é sua extrema simplicidade para quem está aprendendo, mas ainda assim, dispõem de muitos recursos avançados para os programadores profissionais. (PHP, 2014).
Embora seu desenvolvimento seja focado principalmente na programação do lado do servidor (em que o código é executado em conjunto com um servidor web e acessado
através de um navegador web), o PHP ainda pode ser executado em linha de comando, sem a necessidade de um servidor web ou navegador, ideal para scripts que precisam ser executados regularmente através de agendamento. O PHP não é a melhor opção de linguagem de programação para isso, mas com um bom conhecimento, também é possível desenvolver aplicações desktop utilizando a extensão PHP-GTK. (PHP, 2014).
5.1.3 Sublime Text
O Sublime Text é um editor de texto multiplataforma com versões para Windows, OS X e Linux. Possui um ótimo desempenho, facilidade de customização além de uma série de recursos que podem ser adicionados com o desenvolvimento de plug-ins, que aliado a colaboração de sua crescente comunidade, o Sublime Text vem ganhando cada vez mais recursos e popularidade. Neste projeto, o Sublime Text foi utilizado especialmente na codificação em que foi utilizado a linguagem de programação JavaScript, devido a familiaridade do autor no uso da ferramenta com a linguagem em específico.
5.1.4 JSON
JSON ou JavaScript Object Notation é um formato muito popular de intercâmbio de dados desenvolvido por Douglas Crockford. O formato JSON é baseado em texto, leve e de fácil leitura, é derivado do JavaScript e se assemelha muito com objetos do JavaScript, mas o JSON é independente de linguagem, e seu formato é suportado por todas as linguagens mais populares como C#, PHP, Java, C++, Python e Ruby. (SRIPARASA, 2013).
Ainda segundo Sriparasa (2013) o JSON pode ser utilizado em aplicações web para a transferência de dados, e antes do JSON, o XML foi considerado o escolhido como formato de intercâmbio de dados, mas por uma série de desvantagens do XML como ser um formato mais pesado, detalhado, possuir um maior tamanho em comparação ao JSON. Na era em que smartphones e tablets estão cada vez mais populares, o JSON acabou se tornando o
formato escolhido na internet para o intercâmbio de dados pois além das vantagens que possui contra o XML, o JSON não precisa de nenhuma implementação específica, o próprio motor de JavaScript do navegador (responsável por interpretar e executar o código JavaScript), é capaz de interpretar o formato JSON.
5.1.5 ExtJS
ExtJS é uma biblioteca JavaScript que foi iniciada como uma extensão da biblioteca YUI (Yahoo User Interface), uma popular e poderosa biblioteca JavaScript, provendo a YUI um recurso que lhe faltava, uma API (Application Programming Interface) de fácil utilização e componentes de para uso no mundo real, pois mesmo a YUI ter tentado focar seus esforços em recursos para interface de usuário, não havia muita coi.sa em sua biblioteca que estivesse fácil para uso. (FREDERICK; RAMSAY; BLADES, 2008).
Frederick, Ramsay e Blades (2008) ainda afirmam que a biblioteca Ext fornece uma interface de usuário rica e de fácil utilização, muito parecida com as que encontramos nas aplicações desktop. Isso permite que os desenvolvedores se concentrem nas funcionalidades das aplicações web em vez de questões técnicas.
5.1.6 Eclipse
Eclipse é uma IDE (Integrated Development Environment) muito popular, principalmente em sua utilização para o desenvolvimento com a linguagem de programação Java utilizando a IDE Java, mas ela fornece um ótimo suporte a diversas outras linguagens como C/C++ e PHP através de extensões para sua plataforma. (ECLIPSE, 2014).
PDT (PHP Development Tools) adiciona ao Eclipse um ambiente de desenvolvimento integrado para o PHP, fornecendo todos os componentes necessários para se desenvolver aplicações web em linguagem PHP. (ECLIPSE, 2014).
5.1.7 Twitter
Twitter é uma rede de informações composta por mensagens de até 140 caracteres chamado Tweets, uma forma fácil de encontrar as últimas novidades sobre um assunto de interesse. O Twitter contém informações que podemos considerar importantes, as mensagens dos usuários que seguimos aparecem na página principal, e podemos descobrir as novidades conforme elas vão acontecendo. (TWITTER, 2014).
Uma interface de programação de aplicativo ou API (Application Programming Interface), é o que permite que um aplicativo compartilhe os dados com o resto do mundo. Uma API é como um web site sem as informações desnecessárias, acessado pela requisição de uma URL que retorna dados estruturados ao invés de um web site. (MAKICE, 2009).
É através da API do Twitter que milhares de aplicativos acessam seus dados e estendem suas funcionalidades ou criam suas próprias soluções, como programaticamente extrair, armazenar e analisar grande quantidade de informações geradas por usuários utilizando o Twitter.
5.1.8 MongoDB
MongoDB é um sistema de gerenciamento de banco de dados projetado para aplicações web e infraestrutura de internet, seu modelo de dados e estratégias de persistência foram feitos para suportar uma alta frequência de leitura e escrita, fácil escalonamento com proteção automática contra falhas. O MongoDB é muito atrativo não só por sua estratégia de escalonamento, mas também por seu modelo de dados intuitivo em que um modelo de dados de documento pode ser representado em ricas estruturas de dados hierárquicas, e frequentemente é possível faze-lo sem os complicados joins em múltiplas tabelas. (BANKER, 2012).
Segundo Chodorow e Dirolf (2010) o MongoDB é um banco de dados orientado a documentos, não relacional, e o principal motivo para sair dos bancos de dados relacionais, é tornar o escalonamento mais fácil, mas além dessa, existem outras vantagens. A ideia básica é substituir o conceito de “linha” por um modelo mais flexível, o “documento”. Permitindo
