Agenda-structuring: The regional strain

Em seu “O Manifesto da Transdiciplinaridade”, Nicolescu (1999, p. 10 e 11) expõe sua preocupação com o ecossistema da informação e comunicação:

A revolução informática que se desenrola diante de nossos olhos maravi- lhados e inquietos poderia levar a uma grande liberação do tempo, a ser as- sim consagrado à nossa vida e não, como para a maioria dos seres sobre esta Terra, à nossa sobrevivência. Ela poderia levar a uma partilha de co- nhecimentos entre todos os humanos, prelúdio de uma riqueza planetária compartilhada. Mas, aí também, nada acontece. Os comerciantes apres- sam-se para colonizar o espaço cibernético e profetas incontáveis só nos fa- lam dos perigos iminentes. Porque somos tão inventivos, em todas as situa- ções, em descobrir todos os perigos possíveis e imaginários, mas tão po- bres quando se trata de propor, de construir, de erguer, de fazer emergir o que é novo e positivo, não num futuro distante, mas no presente, aqui e a- gora?

Este cenário que inquieta Nicolescu (1999) se assemelha e até parece ser o mesmo descrito por Castells (1999) ao afirmar que, devido as suas características estruturais de flexibilidade e adaptabilidade, as redes parecem acomodar a organi- zação “nova economia” que, em princípio, não implicaria no fim do capitalismo, mas no inicio da prática de um capitalismo diferenciado pelas duas principais característi- cas, global e estruturado em rede. “A partir destas redes o capital é investido por todo o planeta e em todos os setores” (CASTELLS, 1999, p. 567). Assim, as TIC es- tariam gerando e aperfeiçoando conhecimento e informação das quais dependem o capital financeiro para sua operação e concorrência, ou seja, Castells (1999) associa as TIC à evolução do capitalismo e ao paradigma liberal. E continua:

Nesse cassino global eletrônico, capitais elevam-se e diminuem drastica- mente, definindo o destino de empresas, poupanças familiares, moedas na- cionais e economias regionais. O resultado na rede é zero: os perdedores pagam pelos ganhadores. Mas os ganhadores e os perdedores vão mudan- do a cada ano, a cada mês, a cada dia, a cada segundo. (CASTELLS, 1999, p. 568)

Mas se assim o fosse, ou seja, se, na média, não há ganhadores ou perdedo- res, como explicar as crises financeiras de 2008 e a atual de 2011?

O próprio Nicolescu (1999), se referindo aos atuais estágios do conhecimento alcançado pela humanidade, afirma que “paradoxalmente, tudo está estabelecido

para nossa autodestruição, mas tudo também está estabelecido para uma mutação positiva comparável às grandes reviravoltas da História.”. Não seria a cultura da par- ticipação descrita por Shirky (item 2.2.1) inserida no atual ecossistema da informa- ção e comunicação, um dos ingredientes que faltava para dar início a esta “mutação positiva”, o princípio de uma “grande reviravolta na história”?

Faz-se a opção por caracterizar o atual ecossistema da informação e comuni- cação como um ecossistema onde as tecnologias estão provendo, não somente o já citado “cassino eletrônico de capitais”, mas também o meio para que a sociedade, por dispor de um vasto tempo livre, participe de forma mais ativa e colaborativa na doação de suas “expertises” na construção de uma riqueza comum (planetária).

As TIC há muito diminuíram as distâncias entre as pessoas e por agora a a- doção do uso de smartphones (cuja concepção ultrapassa em muito as simples fun- ções de um aparelho celular comum, pois nele, assim como acontece com os com- putadores, pode-se acessar a Internet, instalar programas, etc.) adicionou o quesito mobilidade. Atualmente, pode-se conectar sem a dependência de cabos ou fios, a qualquer hora e de qualquer lugar, mesmo quando em movimento. O acesso à In- ternet e seus serviços via smartphone denota a importância de se disponibilizar in- formações acessíveis por este tipo de aparelho.

Mas se o uso de sites de redes sociais vem impactando em larga escala no envolvimento e engajamento das pessoas e de grupos na construção de coisas posi- tivas, em questões relativas à cidadania e à socialização, por que não inserir as BD neste contexto, onde o excedente cognitivo (a matéria prima), as TIC (o meio), a o- portunidade manifestada pelos serviços disponibilizados por intermédio dos sites de redes sociais, da utilização de serviços disponíveis pelo LD e API Web e de pessoas motivadas intrinsecamente?

Antes mesmo da construção física de um banco de dados que compõe um sistema computacional, é necessário que se faça um planejamento que abranja os requisitos e o escopo desse sistema, determinando quais objetos e acontecimentos serão considerados. Uma das formas de realizar tal tarefa é através da concepção de um modelo de dados (CALDEIRA, 2009)

2.3 MODELO DE DADOS

e com diferentes significados. De um modo geral, um modelo de dados é um concei- to que descreve um conjunto de ferramentas conceituais usadas para representar (modelar) entidades do mundo real e seus relacionamentos (SILBERSCHATZ et al., 1999). Do ponto de vista de banco de dados, estas ferramentas conceituais devem no mínimo definir a estrutura e a descrição dos tipos de dados, podendo ainda con- ter os operadores ou regras de inferência e as regras de integridade (CODD, 1980 apud ANGLES e GUTIERREZ, 2008).

Desde os primórdios da utilização dos bancos de dados, vários modelos de dados foram propostos (Figura 9), e o debate sobre qual modelo de dados é mais adaptável para determinado sistema, é praticamente interminável.

Figura 9: Evolução dos modelos de banco de dados representados pelos retângulos. As setas indicam as bases teóricas, representadas pelos círculos, que influenciaram tais

modelos. No lado esquerdo é mostrada a linha do tempo em anos

2.3.1 Modelo Entidade-Relacionamento

Dentre os modelos de dados já propostos, o modelo Entidade - Relaciona- mento – MER (CHEN, 1976) é atualmente o mais amplamente difundido (LIMA, J. A. DE O., 2008). Neste modelo, o mundo real é formado por um conjunto de objetos chamados entidades (uma coisa ou um objeto que possui atributos - um conjunto de propriedades e valores) e seus relacionamentos (associação entre uma ou mais en- tidades) (SILBERSCHATZ, A. et al., 1999). Por exemplo: uma música poderia ser modelada como uma entidade e seus atributos poderiam ser: seu nome; o intervalo de tempo de sua duração, sua tonalidade, etc. Como exemplo de relacionamento entre uma entidade Música e uma outra entidade Compositor, é possível se ter a associação criada-por , conforme mostrado na Figura 10.

Figura 10: Entidades Música e Compositor e o relacionamento “criada por”

O modelo relacional serve-se de uma coleção de tabelas para representar tantos os dados quantos as relações entre eles. Cada tabela pode ser definida por um conjunto de linhas e colunas. Semanticamente, linhas denotam objetos e colunas denotam os atributos. Assim, o dado em uma determinada linha/coluna é o valor da propriedade representada pela coluna para esse objeto representado pela linha (SILBERSCHATZ et al., 2006). Normalmente, um domínio problema é modelado uti- lizando-se de várias tabelas de forma a evitar a duplicação de dados. Este processo é conhecido como normalização de dados. A fim de unificar os dados em tabelas diferentes, é utilizado um comando join. Este comando combina duas tabelas quan- do colunas de uma tabela fazem referência às colunas de outra tabela. Manter essas referências em um estado consistente é conhecido como integridade referencial. Es- ta é uma solução clássica que tenta dar flexibilidade para um banco de dados rela- cional ( MISHRA e EICH,1992 apud RODRIGUEZ e NEUBAUER, 2010), mas que reconhecidamente demanda processamento. Ao contrário, os bancos de dados que utilizam o modelo de grafos não armazenam dados em tabelas, mas sim em uma única estrutura denominada grafo. Não existe, portanto, operações “join”, pois cada vértice e aresta tem uma referência direta ao seu vértice ou aresta adjacente (RODRIGUEZ, M. A.; NEUBAUER, P., 2010).

De acordo com Silberschatz et al. (2006), desde os anos 70, novas caracterís- ticas (multimídia, hipertexto), oriundas de aplicações, evidenciaram uma certa inca-

pacidade do MER na modelagem dessas características. Para atender a estas de- mandas, as aplicações passaram a serem escritas utilizando-se de um estilo de lin- guagem de programação orientada a objeto, onde as definições de objetos e classes são fortemente mapeadas.

Ocorre que, quando um sistema de gerenciamento de banco de dados rela- cional está sendo usado por um programa escrito em um estilo ou linguagem orien- tada a objetos, registra-se um conjunto dificuldades técnicas e conceituais que parti- cularmente acontece quando os objetos ou definições de classe são mapeados em um banco de dados relacional. A este conjunto de dificuldades, ou seja, a incompati- bilidade conceitual entre o modelo relacional de dados e o modelo orientado a obje- to, se dá o nome “Object-relational impedance mismatch” (Figura 11).

Figura 11: “Object-relational impedance mismatch”

Fonte: Autor (baseado em ObjectFocus Inc.)

As empresas de software têm respondido a esta incompatibilidade através de (i) diferentes produtos/ferramentas que permitem aos desenvolvedores trabalharem no domínio da orientação objeto e “garantindo” o mapeamento desses objetos nas tabelas do mundo relacional e (ii) com o disponibilização de frameworks (ambientes de desenvolvimento) que prometem lidar com a persistência das classes e dos obje- tos, permitindo ao desenvolvedor manter o foco no domínio do negócio.

Ambas as soluções protegem o desenvolvedor do mundo relacional, embora mesmo com as restrições de tempo de desenvolvimento, de tempo de execução, ou de ambos, o problema principal (“Object-relational impedance mismatch”) permane- ce: o modelo relacional é incompatível com o atual paradigma de desenvolvimento de software (IRELAND et al., 2009; SASIREKHA, 2011).

do desempenho do modelo relacional reside na constatação de que é crescente a complexidade das aplicações e os dados que nelas são manipulados estão cada vez mais fragmentados e semi-estruturados. Possuem característica heterogênea e são inerentes a esquemas que evoluem rapidamente, o que resulta em tabelas com va- lores esparsos (tabelas com poucos valores preenchidos), como mostrado na Figura 12.

Figura 12: Como os dados estão distribuídos num banco de dados relacional

Indo além da característica semi-estruturada, muitos conjuntos de dados (data sets) estão naturalmente organizados em forma de rede (grafos), estrutura que vem se mostrando eficiente para armazenamento de dados, com aplicações em Web Semântica, redes sociais; sistemas de inteligência artificial, etc. (NEO DATABASE TECHNOLOGY, 2006). O modelo relacional pode capturar uma estrutura de dados orientada a grafos, mas vem se mostrando inapropriado quando se trata de trans- passar49 essa rede, objetivando a obtenção de informações (VICKNAIR et al., 2010). 2.3.2 Modelos NoSQL

Além dessas limitações, duas outras das atuais tendências vêm chamando a atenção da comunidade de software internacional (NEO DATABASE TECHNOLOGY, 2006; SASIREKHA, 2011): (i) o exponencial crescimento do volume de dados gerado pelos usuários e sistemas (atual ecossistema da informação e co- municação) acelerado em parte pela grande concentração de sistemas distribuídos (como Amazon e Google e outros serviços de nuvem); e (ii) o aumento da interde-

49 _{O termo Graph traversal refere-se à busca de informação por entre os elementos (ou seja, entre os} vértices e arestas) de uma estrutura em forma de grafo, utilizando-se alguma formula algorítmica (RODRIGUEZ, NEUBAUER e BOGICEVIC, 2010).

pendência e complexidade dos dados, acelerado pela Web 2.0, sites de redes soci- ais e padrões de acessos abertos para diversas fontes de dados provenientes de um grande número de diferentes sistemas (Linked Data, por exemplo). Estas tendências vêm fazendo com que sejam desenvolvidas novas alternativas ao MER denomina- das NoSQL50 _{(acrônimo da língua inglesa para “Not Only SQL”) ou seja implica em}

considerar, para a manipulação dos dados, alternativas que não seja somente aque- la preconizada pelo MER além de considerar outras características, tais como ser: distribuído, open-source (cultura da colaboração) e horizontalmente escalável51. Ou- tras características muitas vezes ainda se aplicam tais como: livre de esquema; faci- lidade em suporte a replicação; API52 simples e capacidade de armazenamento de enormes quantidades de dados entre outras mais. A intenção original do movimento NoSQL foi a de construir modernos bancos de dados para a escala da Web (global, grande quantidade de dados, inteligência coletiva). O movimento começou no início de 2009 e está crescendo rapidamente.

No âmbito do NoSQL existem vários tipos de soluções que podem ser classi- ficadas de acordo com o seu modelo de dados, a saber:

• Armazenamento de pares de Chave-Valor (C-V) estão fortemente baseadas na solução denominada “Dynamo” adotada pela Amacom.com há alguns anos a- trás (DECANDIA et al., 2007). Trata-se de um BD especializado para tratar es- pecificamente do grande volume de informações no contexto do comércio ele- trônico. Seu modelo de dados consiste numa coleção global de pares de C-V dispostas em longas tabelas de somente duas colunas. A confiabilidade em es- cala maciça é um dos maiores desafios enfrentamos pela Amazon.com, res- ponsável por uma das maiores operações de comércio eletrônico do mundo, onde até mesmo a menor falha na disponibilização do serviço acarreta em im- portantes conseqüências financeiras e impactos na confiança do cliente. A pla- taforma da Amazon.com, que fornece serviços para vários sites em todo o mundo, é implementada em cima de uma infra-estrutura de dezenas de milha-

50 _{http:// http://nosql-database.org/. Acesso em 30/10/2011.}

51 _{habilidade de manipular porções crescente de dados de forma uniforme sem a degradação dos} sistemas que utilizam estes dados.

52 _{API é o acrônimo da língua inglesa para Application Programming Interface ou interface para o} desenvolvimento de aplicativos. “É um conjunto de rotinas e padrões estabelecidos por um software para a utilização das suas funcionalidades por aplicativos que não pretendem envolver-se em deta- lhes da implementação do software, mas apenas usar seus serviços” (http://foldoc.org/Application+Program+Interface).

res de servidores e componentes de rede localizados em datacenters ao redor do mundo. Nessa escala, pequenos e grandes componentes falham continua- mente e a forma como é gerido o estado persistente em face dessas falhas dri- ves a confiabilidade e escalabilidade dos sistemas de software. Como exemplo deste tipo de banco de dados temos: Kai53, Voldemort54, e Dynomite55 entre ou- tros;

• As implementações baseadas em colunas no Big Table, oriundas da experiên- cia da Google (CHANG et al., 2006), que utiliza de sistemas de armazenamen- to distribuído para o gerenciamento de dados estruturados numa escala muito grande (pentabytes de dados distribuídos através de milhares de servidores). Muitos projetos de armazenamento de dados do Google, incluindo indexação Web, Google Earth e Google Finance, estão sendo armazenados no Bigtable. Estas aplicações exigem do Bigtable de maneiras diferentes, tanto em termos do volume dos dados (a partir de URLs para páginas Web de imagens de saté- lite) quanto de requisitos de latência (do processamento em massa em back- end para mostrar os dados em tempo real). Apesar destas demandas variadas, o Bigtable, tem se mostrado uma solução flexível e de alta performance para todos esses produtos Google. Outros bancos de dados desta categoria dispo- níveis são: Hbase56 _{e HypeTable}57 _{entre outros;}

• Armazenamento de documentos, inspirado no banco de dados Lotus Notes da IBM58. A lógica aqui é ao invés de fragmentar os dados de um documento, co- mo por exemplo, uma ficha de inscrição, e distribuí-los entre linhas e colunas, armazena-se o documento como uma entidade única. CouchDB59, OrientDB60 e MongoDB61 entre outros.

• Armazenamento de dados em estrutura de grafo (baseados em nós e relacio- namentos) que, ao invés de tabelas (linhas e colunas), permitem ainda maior agilidade e rapidez no desenvolvimento. São utilizadas em aplicações cujo foco

53 _{http://sourceforge.net/projects/kai/. Acesso em 30/10/2011.} 54 _{http://project-voldemort.com/. Acesso em 30/10/2011.} 55 _{https://github.com/cliffmoon/dynomite/wiki/dynomite-framework. Acesso em 30/10/2011.} 56 _{http://hbase.apache.org/. Acesso em 30/10/2011.} 57 _{http://hypertable.org/. Acesso em 30/10/2011.} 58 _{http://www-01.ibm.com/software/lotus/products/notes/. Acesso em 30/10/2011.} 59 _{http://couchdb.apache.org/. Acesso em 30/10/2011.} 60 _{http://www.orientechnologies.com/. Acesso em 30/10/2011.} 61 _{http://www.mongodb.org/. Acesso em 30/10/2011.}

está mais na interconectividade, nos relacionamentos do que nos dados em si. Entre as implementações disponíveis dessa categoria estão Infinitegraph62_{, In-}

foGrid63 e Neo4J64. 2.3.3 Modelo de grafos

O modelo de grafos65 _{vem sendo considerado no processo de desenvolvimen-}

to de banco de dados desde a introdução do modelo semântico e tem, mais recen- temente, forte influência na modelagem orientada a objeto. Seu uso, no entanto, como banco de dados e em linguagens de manipulação de dados é menos comum.

O modelo de dados baseados em grafos possui 3 tipos de abstrações: (i) nós (o equivalente as linhas do MER) (ii) relacionamentos entre os nós e (iii) tantos os nós quanto os relacionamentos, possuem propriedades constituídas de pares de chave-valor (C-V).

A título de exemplo, na Figura 13 é mostrada a modelagem de uma rede so- cial (de amigos) considerando os personagens do filme Matrix66. O que primeiramen- te deve-se considerar é a identificação das entidades do domínio sendo que todas estas entidades são representadas por nós. No primeiro caso, uma pessoa cujo no- me é “Thomas Anderson” de 39 anos de idade, está representada por um nó e as propriedades de C-V (nos diversos formatos como: inteiros, ponto flutuante, strings) que representam os atributos nome e a idade. Em seguida, temos outros nós (enti- dade/pessoa) com seus respectivos atributos de C-V e conectando estes nós estão os relacionamentos tipificados como “knows” (conhece). Os relacionamentos, assim como os nós, podem possuir propriedades de C-V representando seus atributos co- mo é o caso entre os nós 1 e 2 existe o relacionamento “known” (conhece) que tem um atributo “age”( há quanto tempo) cujo valor é “3 dias” (minuto 21 do vídeo)

62 _{http://www.infinitegraph.com/. Acesso em 30/10/2011.} 63 _{http://infogrid.org/. Acesso em 30/10/2011.}

64 _{http://neo4j.org. Acesso em 30/10/2011.}

65 _{O conceito de bancos de dados de grafo é relativamente novo. Embora seja possível implementar} um modelo de grafo em qualquer tipo de banco de dados (por exemplo, bancos de dados relacionais, bancos de chave / valor, bancos de dados de documentos), um banco de dados de grafo, no contexto desta dissertação, é aquele que faz uso de referências diretas entre vértices e arestas adjacentes. Como tal, estes bancos de dados de grafo são sistemas que são otimizados para realizar operações sobre o grafo (percorrer um caminho entre os nós e arrestas de um grafo através de operações nomeadas como “traversals gráph”. Neo4j (Neo4j.org) é um exemplo deste tipo de banco de dados. 66 _{Link sobre o filme Matrix no site “Internet Movie Database”: http://www.imdb.com/title/tt0133093/.} Acesso em 30/10/2011.

Figura 13: Exemplo de modelagem de rede social

Fonte: Neo Database Technology (2006)

Uma das características principais do GraphDb é a sua flexibilidade e sua ca- pacidade para representar a complexidade dos dados (MELLO et al., 2000).

2.3.4 Discussão

Procurou-se aqui introduzir o assunto modelo de dados e descrever algumas das principais diferenças entre os modelos MER e graphDb. Discussões sobre qual modelo é mais adaptável para determinado sistema vem ocorrendo desde os pri- mórdios dos sistemas computacionais de bancos de dados. Apesar da atual supre- macia do primeiro modelo, viu-se aqui que o segundo é mais flexível e pode ser uma alternativa para se atender as sempre mutantes necessidades de informações dos usuários e as características da Web de dados ligados.

Os atuais desafios no desenvolvimento de aplicações para a Web, do expo- nencial crescimento do volume de dados, da popularização de estruturas de data- sets em forma de rede, e a evidência de certa incapacidade do MER em gerir os da- dos neste contexto, vêm fazendo com que grandes organizações procurem alternati- vas para a modelagem de dados, buscando modelos mais eficazes e eficientes para a gestão de seus negócios, naquilo que vem se chamando movimento NoSQL.

Ao se considerar o pensamento complexo, não se pode deixar de observar que da maneira como tradicionalmente uma BD é concebida e implementada, algu- mas de suas propriedades são desconhecidas na medida em que seus integrantes

(objetos informacionais, bibliotecários, usuários, etc.) não estão totalmente expostos a uma interação e se mantêm isolados. Mas, ao propor uma BD no atual ecossiste- ma da informação e comunicação com o nível de integração e o número de intera- ções exigidas entre os objetos informacionais, bibliotecários, usuários, outros dados “linkados”, entre outros, podem resultar na emergência de novas propriedades até então não consideradas. Sobre esta ótica, supõe-se que a adoção de um modelo de dados de esquema livre, e, portanto mais flexível, poderia melhor se adaptar a estas mudanças.

O que se pretende ao fazer essa escolha é atentar às expectativas geradas pela necessidade de um modelo livre de esquema (free squema) por acreditar: (i) que as necessidades dos usuários estão em constante mutação; (ii) que uma BD não pode continuar isolada (como será aclarado mais adiante) e (iii) ela precisa se integrar facilmente com outros domínios de informações. Assim, tendências como a de relacionar e misturar os dados de uma aplicação com aqueles advindos da nu- vem ou de API de sites de redes sociais (mashup) e como o modelo de dados de grafos, parecem ser as mais indicadas para atender às expectativas.