Você está na página 1de 78

FUNDAO EDSON QUEIROZ

UNIVERSIDADE DE FORTALEZA UNIFOR















O Estado da Arte em Bancos de Dados Orientados a
Documentos











Leonardo Eloy Abranques de Oliveira










Fortaleza Cear
2009
Leonardo Eloy Abranques de Oliveira










O Estado da Arte em Bancos de Dados Orientados a
Documentos







Monografia apresentada para obteno dos
crditos da disciplina Trabalho de Concluso
do Curso do Centro de Cincias
Tecnolgicas da Universidade de Fortaleza,
como parte das exigncias para graduao no
Curso de Informtica.

Orientador: M.Sc. Raimundo Tales Benigno Rocha Matos














Fortaleza Cear
2009



O Estado da Arte em Bancos de Dados Orientados a
Documentos



Leonardo Eloy Abranques de Oliveira




PARECER: _____________________________________________

DATA: ___/___/___




BANCA EXAMINADORA:



________________________________________________
Prof. Raimundo Tales Benigno Rocha Matos, M.Sc.
(Orientador)


________________________________________________
Prof. Jos Maria Monteiro Filho, Dr.
(Examinador)










































Fora da caridade no h salvao.
Allan Kardec





AGRADECIMENTOS


Agradeo aos meus pais, Samuel e Helena, por sempre confiarem em
mim e nas decises que eu tomei ao longo da minha vida, servindo de modelo
de carter e personalidade que tento aplicar todos os dias. Aos meus irmos,
Delano e Samuel Filho, por sempre estarem presentes nos momentos mais
importantes.

minha esposa Emilze, cuja dedicao, amor, carinho e presena me
tornou um melhor homem, me ajudando a crescer e para juntos enfrentarmos
as provas da vida. Meu amor cresce por voc a cada dia.

Aos professores Jos Maria Monteiro, Tales Rocha Matos e ngelo
Brayner, por me guiarem ao longo deste e outros trabalhos que conclumos
com muito sucesso.

Ao meu amigo Fabrcio Digenes, por ajudar na reviso e discusso deste
trabalho.




RESUMO

Este trabalho apresenta o Estado da Arte em Bancos de Dados
Orientados a Documentos (BDODs), um novo paradigma na modelagem e
armazenamento de dados. Os BDODs so projetados para trabalhar com
dados em evoluo e modelados como documentos do mundo real. Este
tambm o mesmo conceito da World Wide Web, onde pessoas compartilham
bilhes de documentos e recursos. Os BDODs utilizam conceitos avanados de
replicao e distribuio de dados, compartilhando tambm das principais
caractersticas do protocolo HTTP como a escalabilidade. Este trabalho analisa
a principal implementao de referncia que o CouchDB, um BDOD
distribudo e livre de esquema e que implementa uma API denominada
RESTful para consulta e manipulao de dados.

Palavras-chave: Bancos de Dados Orientados a Documentos, CouchDB,
Bancos de Dados No-Convencionais.



ABSTRACT

This paper presents the State of the Art in Document-Oriented
Databases (DODB), a new data storage and modeling paradigm. DODBs are
designed to work with evolving data and real world documents. This is also the
main concept of the World Wide Web, where people share billions of different
documents and resources. DODBs use advanced data replication and
distribution concepts, also sharing HTTPs main features, such as scalability.
This paper analyzes CouchDB, a schema-free, distributed DODB, which uses a
RESTful API for data querying and manipulation.

Keywords: Document-Oriented Databases, CouchDB, Non-Conventional
Databases.















SUMRIO
CAPTULO 1 INTRODUO................................................................................... 7
1.1 OTIVAO ......................................................................................................... 7
1.2 TARACTERIZAO DO PROBLEMA ...................................................................... 10
1.3 OBJETIVOS.......................................................................................................... 12
1.4 J STRUTURA DO TRABALHO ................................................................................ 12
CAPTULO 2 COUCHDB........................................................................................ 14
2.1 4NTRODUO ...................................................................................................... 14
2.2 TPACHE COUCHDB............................................................................................ 14
2.2.1 Documentos ................................................................................................ 16
2.2.2 Propriedades Transacionais....................................................................... 17
2.2.3 Compactao .............................................................................................. 18
2.2.4 Segurana e Validao ............................................................................... 19
2.2.5 Replicao .................................................................................................. 20
2.2.6 Implementao............................................................................................ 22
2.2.7 Administrao............................................................................................. 24
2.3 UOMPARATIVO RELACIONAL E ORIENTADO A DOCUMENTOS ............................. 25
2.3.1 Modelagem de Dados ................................................................................. 25
2.3.2 Estado Global de Recursos......................................................................... 28
2.3.3 Propriedades Arquiteturais ........................................................................ 30
2.3.4 Junes........................................................................................................ 31
2.4 CONSIDERAES FINAIS ..................................................................................... 32
CAPTULO 3 RECUPERAO DE DADOS........................................................ 34
3.1 4NTRODUO ...................................................................................................... 34
3.2 T APREDUCE....................................................................................................... 34
3.2.1 Crticas........................................................................................................ 36
3.3 DIEWS................................................................................................................. 38
3.3.1 Exemplos..................................................................................................... 39
3.4 EONSIDERAES FINAIS ..................................................................................... 45
CAPTULO 4 INTERFACE DE CONSULTAS..................................................... 47
4.1 7NTRODUO ...................................................................................................... 47
4.2 TRODU47
4.2.1 Principais Caractersticas .......................................................................... 49
4.3 TNTERFACE DE CONSULTAS................................................................................. 56
4.3.1 Seleo........................................................................................................ 57
4.3.2 Insero ...................................................................................................... 57
4.3.3 Atualizao ................................................................................................. 59
4.3.4 Remoo...................................................................................................... 62
4.3.5 Utilizando Views ......................................................................................... 63
4.4 NONSIDERAES FINAIS ..................................................................................... 65
CAPTULO 5 CONCLUSO E TRABALHOS FUTUROS................................. 68
BIBLIOGRAFIA .......................................................................................................... 71
VI



LISTA DE FIGURAS

Figura 2.1. Exemplo de bloqueio em uma transao relacional. 22
Figura 2.2. Exemplo de transao em um BDOD. 22
Figura 2.3. Interface do Futon. 25
Figura 2.4. Modelo de uma nota fiscal. 27
Figura 2.5. Cartes de visita. 28
Figura 3.5. O processo de execuo do MapReduce. 35
Figura 3.6. O fluxo de utilizao de um sistema de blogs. 40
Figura 3.7. Representao de um blog como um documento. 41
Figura 4.6. Diagrama de Classes representando a exposio de servios de
um sistema de compras.
54
Figura 4.10. Resultado da consulta realizada com o mtodo GET a uma
base de documentos CouchDB.
58
Figura 4.12. Resultado de uma insero realizada atravs do mtodo PUT
do HTTP para o CouchDB.
59
Figura 4.14. Requisio de atualizao no CouchDB. 61
Figura 4.15. Primeira reviso cadastrada no banco de dados do documento
sendo trabalhado.
61
Figura 4.16. Segunda reviso do documento. 62
Figura 4.19. Resultado de uma requisio remoo de um documento junto
ao servidor do CouchDB.
63
Figura 4.20. Criao de uma view no CouchDB, utilizando o Futon, uma
interface de administrao do banco de dados.
65
Figura 4.21. Execuo de uma consulta a uma view. 65






















VII


LISTA DE TABELAS

Listagem 3.4. Exemplo de dois documentos que representam posts em um
blog, exibidos aqui utilizando a notao JSON.
41
Listagem 3.5. Funo de mapeamento para emisso de chaves
intermedirias preparadas para serem somadas durante a fase de reduo.
42
Listagem 3.6. Chaves intermedirias geradas partir da chamada da
funo de mapeamento mostrada na listagem 3.5.
43
Listagem 3.7. Funo de reduo que obtm as chaves e os valores
intermedirios gerados pela funo de mapeamento (listagem 3.5).
43
Listagem 3.8. Resultado da sada da funo de reduo (listagem 3.7). 43
Listagem 3.9. Sumrio final da execuo do processo de MapReduce. 44
Listagem 3.10. Funo de mapeamento para emisso de chaves
intermedirias preparadas para serem somadas durante a fase de reduo.
44
Listagem 3.11. O resultado da execuo da funo de mapeamento,
agrupando o ttulo e data de um post por autor.
45
Listagem 3.12. Funo de mapeamento para emisso de chaves
intermedirias preparadas para serem somadas durante a fase de reduo.
45
Listagem 3.13. Resultado final da consulta, aps a execuo da funo de
reduo.
44
Listagem 3.14. Sumrio da execuo das funes de mapeamento e
reduo.
44
Listagem 4.1. Sintaxe de um Universal Resource Identifier (URI). 49
Listagem 4.2. Exemplos de Universal Resource Identifier (URI). 49
Listagem 4.3. Exemplo de atributos com identificadores globais, utilizando a
estrutura de uma URI.
51
Listagem 4.4. Exemplo de obteno de colees atravs de identificadores
nicos.
51
Listagem 4.5. A ligao entre recursos permite que o cliente possa mudar o
estado da aplicao atravs do consumo de um link.
52
Tabela 4.7. Mapeamento entre recursos e os mtodos do protocolo HTTP,
indicando quais funes so realizadas de acordo com cada mtodo.
54
Listagem 4.8. Exemplo de requisio HTTP onde o cliente informa quais
tipos de dados est apto a receber.
55
Listagem 4.9. Requisio de seleo em uma base de dados CouchDB
utilizando o protocolo HTTP.
57
Listagem 4.11. Requisio de insero de documento em uma base
CouchDB utilizando o mtodo PUT, exemplificando a incluso de um novo
campo.
59
Listagem 4.13. Envio de uma requisio PUT para atualizar o documento. 60
Listagem 4.17. Exemplo de um requisio de remoo de documento,
informando o nmero da reviso como parmetro juntamente com a URI.
62
Listagem 4.18. Requisio que realiza a remoo da reviso declarada no
cabealho If-Match.

63




VIII





CAPTULO 1 Introduo

1.1 Motivao

Em princpio, os documentos so como uma ferramenta bsica para
regulao e estruturao de comunicao dentro de um grande nmero de
organizaes. O papel desempenhado pelos documentos reflete sua
importncia dentro destas organizaes, por ainda representar estruturas
bastante utilizadas, onde os dados neles contidos ainda definem a forma como
a informao trafega e difundida entre as pessoas que consomem estes
(Sierra, et al., 2004).

Kowarski e Lopez (Kowarski & Lopez, 1982) definiram que um
documento uma forma de comunicao, escrita por um autor a fim de
comunicar um objetivo especfico. Os documentos so compostos de
elementos como texto escrito, tabelas, grficos e imagens. Tambm foi
destacado que estes elementos so combinados a fim de seguir uma ordem
lgica, sendo apresentados de uma forma que atravessa toda uma organizao
funcionando como portador de informaes. Um documento evolui dentro de
um contexto organizacional. Esta evoluo se d atravs da natureza dos
dados contidos no documento e o processo ao qual o documento est
suscetvel a estar inserido.

Os autores definiram que os documentos possuem trs aspectos
bsicos: interno, externo e funcional. Os aspectos internos dizem respeito
forma como os dados esto estruturados no que tange as suas caractersticas
visuais (formato do papel, margem, espaamento, entre outros). J o externo,
define como um documento classificado por um nmero de referncia, data


8


de criao, nome de autores e outros critrios. Os aspectos funcionais, poca
da publicao do artigo, definiam como estes dados estariam dispostos dentro
de um Sistema Gerenciador de Banco de Dados (SGBD), cunhando o conceito
de documento eletrnico.

Sierra e outros (Sierra, et al., 2004) anotaram que os documentos
tornaram-se a base para uma grande classe de aplicaes de software. Entre
estas aplicaes, encontra-se a World Wide Web (ou somente Web), originada
na Sua, como uma forma de trocar informaes e documentos pela
comunidade de fsicos que utilizavam a Internet do Centro Europeu de
Pesquisa Nuclear (CERN) (Berners-Lee, 2001). Coulouris e outros (Colouris, et
al., 2007) definem que uma das caractersticas importante da Web a forma
como ela fornece uma estrutura de hipertexto entre os documentos que
armazena, refletindo a necessidade dos usurios de organizar seus
conhecimentos. Estas informaes esto ligadas entre si atravs de links (ou
hyperlinks), que so referncias para outros documentos e recursos
armazenados na Web.

Elmasri e Navathe (Elmasri & Navathe, 2005) observaram trs tipos de
dados que esto contidos em documentos: estruturados, semi-estruturados e
no estruturados. Um pgina Web em Hypertext Markup Language (HTML)
pode conter dados considerados no estruturados, por somente prover uma
indicao limitada dos dados. Um documento HTML define o contedo do
texto, no sua forma. J nos documentos XML, que possuem dados dispostos
em formato semi-estruturado, possvel associar um tipo de dado, tornando o
dado autodescritivo. Desta forma possvel saber a sua definio e o formato
em que ele est definido. J nos dados estruturados o formato est
armazenado em um outro local, no se misturando com os dados.

Considerando as definies supracitadas e tambm as colocaes de
Kowarski e Lopez (Kowarski & Lopez, 1982), observa-se que o HTML buscou
migrar a estrutura de um documento para o contexto eletrnico ainda buscando
honrar sua funo inicial dentro de uma organizao, e a forma como o


9


documento estruturado tambm pode enriquecer ainda mais o valor de sua
informao.

Guo e outros (Guo, et al., 2008) definiram que nas prticas de negcio
do mundo real, um processo de negcio evolui de tal forma que h uma troca
de documentos pertinentes negociao entre parceiros de negcio
conhecidos ou no. Por exemplo, num processo de negociao, um vendedor
pode enviar uma planilha de itens para possveis compradores. Se algum dos
compradores se interessarem pelos itens expostos, pode requisitar uma
proposta ao vendedor. Aps esta fase, uma contraproposta poder surgir, at
que uma das partes aceita a negociao, restando somente a assinatura de um
contrato para cumprir com as devidas obrigaes legais. Este tipo de fluxo de
informaes implica que a essncia de qualquer processo de negociao a
troca de documentos diferentes, mas casualmente relacionados, tal que a
produo de um documento depende da entrada de um documento enviado
anteriormente. Outro exemplo deste processo que a troca de documentos
entre vendedor e compradores pode ter diferentes formatos e termos de uso.
Num processo tradicional de troca de documentos de papel isto pode no ser
um problema, pois os humanos podem encontrar formas flexveis de interpret-
los da forma correta ou retornar o documento para maior detalhamento. Porm,
ainda observam os autores, num moderno processo eletrnico de negcio isso
ser um problema, pois os computadores no podem realizar a diferenciao
semntica de termos sem regras pr-definidas.

Outro fator observado durante a troca de informaes entre vendedor e
compradores que nenhum dos dois precisou consultar outros documentos a
fim de interpretar os dados necessrios da planilha de itens. Isso se d por
causa de caracterstica autodescritiva ou autocontida dos dados (Elmasri &
Navathe, 2005). Por exemplo, considerando que haveria campos para o
comprador preencher com seus dados pessoais, o mesmo no iria somente
informar um cdigo de um segundo documento, e envi-lo ao vendedor, como
se procede no modelo relacional (Codd, 1970). O comprador iria preencher os
campos como nome, endereo e telefone, retornando o documento ao


10


vendedor. esta caracterstica que garante que uma organizao faa
negcios com um cliente que conhece ou no.

Apesar de amplamente utilizados em organizaes, os documentos
pouco foram implementados como modelo de estrutura e armazenamento de
dados. Com o crescimento cada vez maior da web (Greengard, 2009) e os
custos decrescentes de peas de hardware, diversas iniciativas esto surgindo
a fim de utilizar este conceito como o principal para o desenvolvimento de
novas aplicaes.

Considerando que organizaes tratam os documentos como forma
primordial de troca de informao, que os documentos j carregam os dados
necessrios para que estas entidades possam realizar suas atividades-fim e
que j existem mecanismos bastante difundidos de representar estes
documentos no mbito da tecnologia da informao, este trabalho tem como
objetivo apresentar o estado da arte dos Bancos de Dados Orientados a
Documentos (BDOD), no que concerne a forma como os dados so
modelados, armazenados, recuperados e replicados em uma rede de
computadores, comparando as abordagens e tcnicas utilizadas com o
principal modelo de sistema de bancos de dados vigente, os Sistemas
Gerenciadores de Bancos de Dados Relacionais (SGBDRs).

1.2 Caracterizao do Problema

Conforme visto anteriormente, um documento HTML representa uma
estrutura de documentos que remete forma como as informaes so
organizadas e transmitidas dentro das empresas. Tambm foi exposto que as
organizaes utilizam os documentos como um processo natural de troca de
informaes para os mais diversos fins. O problema est na forma como estes
documentos so armazenados e se a forma como esto estruturados fornece
as caractersticas necessrias para que estes documentos sejam utilizados de
forma eficaz por sistemas de informaes.



11


No final da dcada de 1990, com a popularizao da Internet e a
evoluo da Web (Berners-Lee, 2001), os bancos de dados passaram a ter
uma audincia maior, atravs dos sistemas de informaes que foram
desenvolvidos nesta arquitetura e pela sua intrnseca facilidade de uso. Como
o modelo relacional de dados o predominante no mercado, apesar da grande
evoluo de modelos alternativos, como o orientado a objetos (Silberchartz et
al., 2006), a arquitetura Web adotou os SGBDRs como padro de
armazenamento e recuperao de informaes, assim como aconteceu com
aplicaes cliente-servidor. Atualmente, pode-se dizer que para o sucesso de
um projeto de software preponderante a utilizao de um Sistema de Bancos
de Dados.

A despeito da predominncia do modelo relacional, algumas iniciativas
de orientao a documentos surgiram no incio da dcada de 1990. O Lotus
Notes, produzido atualmente pela Lotus Software (aps a compra da empresa
pela IBM em 2007), um produto comercial que fornece solues de
colaborao corporativa, atravs da facilidade de desenvolvimento de
aplicaes como servios de messaging, workflow, gerenciamento de
documentos e conferncia assncrona (Moore, 1995). O sistema possui um
modelo de armazenamento que prov estruturas intuitivas como documentos,
formulrios e campos, assim como um banco de dados. Ainda vendido pela
IBM, o Lotus Notes perdeu mercado para o Microsoft SharePoint e outros
competidores que focaram suas iniciativas na Web.

Os Bancos de Dados Orientados a Documentos foram construdos
tendo a arquitetura Web como principal referncia de implementao. Portanto,
seria mais interessante armazenar e recuperar estas informaes como foram
construdas. Os SGBDRs por definio trabalham com tabelas e suas relaes,
uma linguagem de manipulao e definio de dados (Codd, 1970), que so
estruturas de tabulao de dados, fugindo do conceito dos documentos, que
so estruturas livres, com dados autocontidos e autodescritivos.

Este trabalho tem como objetivo investigar os aspectos de
armazenamento, consulta e recuperao de dados nos Bancos de Dados


12


Orientados a Documentos, apresentando o estado da arte nas tcnicas
utilizadas por implementaes de referncia deste tipo de software.

1.3 Objetivos

O objetivo deste trabalho apresentar o estado da arte das tcnicas
utilizadas em Bancos de Dados Orientados a Documentos. Como objetivo
secundrio, propomos catalogar quais softwares realizam uma implementao
completamente orientada a documentos, sem a utilizao de um SGBDR para
auxiliar na construo das estruturas de dados.

Os objetivos especficos deste trabalho so:

a) Entender o modelo de dados e a forma como so representados e
armazenados os registros orientados a documentos;
b) Compreender como os dados so recuperados e consultados;
c) Estudar as tcnicas de diviso e replicao dos dados, tambm
no que tange a integridade entre ns distribudos;
d) Verificar se os Bancos de Dados Orientados a Documentos
podem prover um melhor suporte para armazenamento e
recuperao de dados livre de esquema.

1.4 Estrutura do Trabalho

No captulo 2 apresentado o CouchDB, a principal implementao de
um banco de dados orientado a documentos. Neste captulo so analisados os
componentes internos do CouchDB, como os seus dados so representados
atravs do JavaScript Object Notation (JSON), a utilizao do algoritmo Multi-
version Concurrency Control (MVCC), onde um cliente tem sempre acesso a
uma viso consistente do banco de dados do incio ao final de uma operao
de leitura e tambm apresentado um comparativo entre os bancos de dados
relacionais e orientados a documentos.



13


O captulo 3 aborda a forma como os dados podem ser recuperados. A
consulta em um banco de dados orientado a documentos segue um conceito
diferenciado, ao passo que sua estrutura foi construda para ser distribuda por
diversos servidores, por isso, neste captulo apresentada a aplicao do
algoritmo MapReduce e sua participao na construo de vises.

No captulo 4 mostrado como a estrutura dos bancos de dados
orientados a documentos tm a vantagem de ter a web como arquitetura base
para sua construo. Esta estrutura pode ser aproveitada atravs da utilizao
do Representational State Transfer (REST), um princpio de programao que
utiliza o conceito de Universal Resource Identifiers (URIs) para disponibilizao
de recursos de leitura, escrita e atualizao de dados atravs do protocolo
Hypertext Transfer Protocol (HTTP).

Finalmente, no captulo 5, apresentada a concluso deste trabalho,
indicando produtos de mercado que podem ser utilizados para estudo, as
inevitveis comparaes com o modelo relacional, as limitaes e dificuldades
encontradas, alm de indicaes para trabalhos futuros.




14





CAPTULO 2 CouchDB

2.1 Introduo


Neste captulo apresentado o CouchDB, um Banco de Dados
Orientado a Documentos (BDOD) livre de esquema e distribudo, que utiliza a
Web como princpio arquitetural. O CouchDB a principal implementao
deste tipo de banco de dados na atualidade e conta com uma srie de
caractersticas que torna a sua utilizao vivel em hardware commodity, ou
seja, mquinas que so usadas como servidores, mas com hardware de baixa
qualidade ou antigos. Os componentes integrantes do CouchDB e as tcnicas
utilizadas para armazenamento e concorrncia tambm sero apresentados.
Em seguida, apresentada uma comparao entre os bancos de dados
relacionais e o orientados a documentos, principalmente no que diz respeito a
modelagem de dados e caractersticas de cada paradigma.

2.2 Apache CouchDB

Esta seo apresenta os componentes e conceitos do CouchDB, um
banco de dados orientado a documentos livre de esquema, acessvel atravs
de uma Application Programming Interface (API) denominada Representational
State Transfer (REST), que trabalha com dados utilizando a notao JavaScript
Object Notation (JSON) (Apache CouchDB, Introduction to CouchDB, 2008).
Alm dos principais componentes do CouchDB, apresentado o Futon, uma
aplicao Web de gerenciamento de instncias deste sistema de banco de
dados.



15


Inicialmente desenvolvido em C++, o CouchDB foi migrado para a
plataforma Erlang OTP no ano de 2008, por causa de sua nfase em tolerncia
a falhas e facilidades com programao distribuda (Lennon, 2009). Neste
mesmo ano, o CouchDB tornou-se um projeto oficial do Apache Group, onde
seu cdigo-fonte liberado de acordo com a licena Apache v2.0, o que
permite a livre modificao e uso do cdigo-fonte produzido pelo projeto,
obrigando apenas a exposio do aviso de copyright e termo de
responsabilidade como descrito na licena Apache em (Apache Group, 2004).

Lennon (Lennon, 2009) observa que o termo Couch um acrnimo
para Cluster of Unreliable Commodity Hardware (Conjunto de Hardware
Commodity No-Confiveis), refletindo o objetivo do banco de dados ser
extremamente escalvel, oferecendo alta disponibilidade e confiabilidade,
mesmo quando executando em um hardware que tipicamente suscetvel a
falhas. O autor ainda observa que no CouchDB os dados so armazenados
em um formato semi-estruturado, utilizando um modelo de views baseado em
JavaScript para a gerao de agregaes e filtros, provendo resultados de
consultas a partir destes documentos semi-estruturados (Apache CouchDB,
Introduction to CouchDB, 2008).

O CouchDB foi desenvolvido tendo como foco principal a Web,
norteando seus esforos para se tornar o banco de dados padro para o
desenvolvimento de aplicaes Web (Lennon, 2009). Parte deste esforo se
deve pela exposio de uma API utilizando a arquitetura REST, detalhada no
captulo 4. O REST utiliza o HTTP como parte integrante de sua arquitetura,
portanto, dizer que o CouchDB possui uma API REST significa que o banco de
dados est pronto para receber requisies de um browser ou qualquer outro
cliente que implemente o protocolo HTTP (Fielding R. T., 2000).

Alm de sua arquitetura ser construda para permitir a criao de
aplicaes Web mais simples, o CouchDB tambm um banco de dados
distribudo, possuindo um mecanismo incremental de replicao com deteco
e gerenciamento bi-direcional de conflitos, possibilitadas pela implementao


16


do algoritmo Multi-version Concurrency Control (MVCC) (Apache CouchDB,
Introduction to CouchDB, 2008).

O CouchDB no um banco de dados relacional e nem uma
substituio para este tipo de banco de dados. Sua implementao tambm
no um banco de dados orientado a objetos, muito menos uma camada
orientada a objetos para persistncia de dados (Apache CouchDB, Introduction
to CouchDB, 2008). As prximas sees apresentam os principais
componentes do CouchDB.

2.2.1 Documentos

Para o CouchDB, um documento um objeto composto de campos
nomeados. Estes campos podem ser cadeias de caracteres, nmeros, datas ou
at listas ordenadas e mapas associativos (hashmaps), onde no h limitao
de tamanho para campos (Apache CouchDB, Introduction to CouchDB, 2008).

Os documentos so a unidade primria de dados dentro do CouchDB,
e tambm so utilizados para armazenado de metadados do banco. O modelo
de atualizao de documentos otimista e sem locks, onde alteraes nos
documentos so realizadas por aplicaes clientes e carregadas novamente no
banco de dados. Supondo que um cliente A est editando o mesmo documento
que um cliente B e este ltimo salva suas alteraes, o cliente A recebe um
erro de conflito de edio ao tentar realizar uma atualizao. Uma forma de
resolver este conflito de atualizao abrir a ltima verso do documento e
aplicar novamente as alteraes, realizando a atualizao em seguida.

As operaes de edio (adicionar, editar e remover) no CouchDB so
atmicas, onde deve haver sucesso completo ou falha completa durante a
operao, sempre garantindo que o banco de dados nunca ir armazenar
documentos salvos ou editados parcialmente (Apache CouchDB, Technical
Overview, 2008).



17


A vantagem de utilizar documentos que os dados esto prontos para
armazenamento, ao invs de distribudos entre colunas e linhas ao longo de
arquivos de banco de dados. Quando os documentos so salvos no disco, seus
campos e metadados so armazenados em buffers, de forma seqencial, um
aps o outro (Lennon, 2009).

O CouchDB tambm apresenta um tipo especial de documento,
chamado documento de projeto (design document). Como qualquer outro tipo
de documento utilizado pelo banco, ele tambm declarado atravs da
notao JSON, a nica diferena que neste tipo de documento podem ser
agrupadas uma ou mais definies de views. Por exemplo, caso existam trs
tipos de views que obtenham informaes acerca de um Cliente, estas podem
ser agrupadas num documento de projeto chamado clientes. O captulo 3
apresenta a conceituao terica e prtica das views.

2.2.2 Propriedades Transacionais

O termo ACID, cunhado por Hrder e Rothermel (Hrder & Rothermel,
1987), refere-se s propriedades de atomicidade, consistncia, isolamento de
execuo e durabilidade (atomicity, consistency, isolated execution, durability),
que garantem que transaes de bancos de dados so processadas com
confiabilidade. No CouchDB, todo o layout de arquivos e sistema de commit
est baseado nestes princpios, o que resulta na garantia de um estado sempre
consistente do arquivo de banco de dados. A atualizao de documentos so
serializadas e os leitores de banco nunca so bloqueados ou nunca tm de
esperar por escritores ou outros leitores. A leitura de documentos pode ser
realizada por diversos clientes sem ser bloqueada ou interrompida por
atualizaes concorrentes. Esta caracterstica se deve pela utilizao de um
modelo baseado no algoritmo MVCC, onde cada cliente v um retrato
consistente do banco de dados do comeo at o final da operao de leitura
(Apache CouchDB, Technical Overview, 2008).



18


Cada documento possui um identificador nico e global, sendo estes
valores o identificador de reviso e o identificador do documento, utilizados
para indexao numa rvore B+. A cada atualizao no banco de dados, um
novo nmero de reviso gerado, onde so utilizados posteriormente para
encontrar mudanas incrementais no banco de dados. A atualizao destas
rvores B+ realizada de forma incremental (atualizaes so sempre no final
do arquivo) e simultnea quando documentos so salvos ou removidos. Esta
rvore utilizada para encontrar documentos no arquivo de banco de dados
(Apache CouchDB, Technical Overview, 2008).

Quando um documento atualizado, todos os dados e ndices
associados so gravados no disco, onde um commit transacional garante que o
banco de dados seja deixado em um estado completamente consistente. O
commit realizado em duas fases, onde na primeira fase os documentos e
ndices so gravados em disco de forma sncrona. A segunda fase realiza a
substituio do cabealho da rvore B+ que aponta para os documentos,
sendo a sua escrita em disco realizada em dois pedaos idnticos e
consecutivos, preenchendo os primeiros 4 kilobytes do arquivo de banco de
dados (Apache CouchDB, Technical Overview, 2008). Esta tcnica permite que
no evento de uma falha do sistema operacional ou queda de energia durante a
primeira fase, as atualizaes parcialmente gravadas so ignoradas durante o
reincio do servio de banco de dados. Se a queda ocorre durante a segunda
fase, uma cpia anterior do cabealho do banco de dados j estar gravada, o
que garante a coerncia de todos os dados j gravados no banco. Fora o
cabealho do banco de dados, verificaes e ajustes no so necessrios aps
eventos de queda de energia ou falha de sistema operacional (Apache
CouchDB, Technical Overview, 2008).

2.2.3 Compactao

Segundo Katz (Katz, 2008), os bancos de dados gerenciados pelo
CouchDB crescem a cada atualizao de documento, mesmo que estas
atualizaes sejam remoo de documentos. Para recuperar espao em disco


19


perdido, deve-se executar um processo de compactao do banco de dados,
que ir expurgar todas as revises antigas feitas a um documento e reorganiz-
los no disco para garantir um acesso seqencial mais rpido.

O processo de compactao ocorre de forma quente, ou seja, durante
a execuo do banco de dados. Operaes usuais como leitura, escrita,
replicao e reconstruo de views podem ocorrer durante a compactao,
sendo este processo incremental e passvel de reincio, caso haja necessidade
de iniciar novamente o servio, queda de energia ou falha no sistema
operacional (Katz, 2008).

2.2.4 Segurana e Validao

Por padro, o CouchDB possui dois tipos de permisso de acesso:
administrador e leitura. O acesso de administrador possui controle total sobre
as operaes administrativas do banco (compactao, gerenciamento de views
e replicao), podendo tambm criar outras contas administrativas. A fim de
controlar o acesso de leitura, o CouchDB implementa um documento que
contm uma lista de usurios que podem acessar e alterar documentos
protegidos. Esta lista de acesso tambm estendida para as views, onde caso
um documento esteja protegido, este no ser includo no processamento do
MapReduce (como descrito no captulo 3).

O processo de validao do banco funciona quando h incluso,
alterao ou remoo de algum documento. Aes podem ser realizadas de
acordo com o tipo da alterao, como a criao de uma entrada de auditoria.
Este processo pode ser customizado atravs de uma funo JavaScript, onde
dois argumentos de entrada so passados: o usurio que est realizando as
alteraes e o documento a ser processado. Desta forma, possvel construir
funes de validao baseadas na estrutura de lista de acesso ou at
validaes dinmicas, baseadas no contedo do documento em questo. Caso
haja o processamento correto desta funo, o banco ir salvar as atualizaes
ao documento; caso contrrio, ir abortar as alteraes. Estas validaes so


20


projetadas para funcionarem tanto num n principal do banco como em seus
ns de replicao (Apache CouchDB, Technical Overview, 2008).

2.2.5 Replicao

O CouchDB penaliza a consistncia para priorizar a tolerncia a falhas
e a disponibilidade, atravs do particionamento de dados por diversos
servidores, permitindo que um cliente sempre acesse uma verso dos dados,
desta forma, h sempre uma consistncia eventual da informao armazenada
(Apache CouchDB, 2008). Para compreender melhor os mecanismos de
replicao utilizados pelo CouchDB, esta seo apresenta os conceitos e
estruturas utilizadas pelo banco para recuperao e armazenamento de dados
em mltiplos ns.

2.2.5.1 Motor de Armazenamento

O motor de armazenamento do CouchDB baseado numa verso
modificada de uma rvore B+, uma estrutura de dados que permite buscas,
inseres e remoes de ns em complexidade logartmica. Todos os dados
internos, documentos e views utilizam esta estrutura de armazenamento. Os
dados no banco so representados utilizando pares de chave e valor e
armazenados na rvore B+, o que permite uma pesquisa rpida por chaves ou
por faixas de chaves, com complexidade e ,
respectivamente, onde N representa a quantidade de chaves a ser pesquisada
e K a faixa das chaves (Anderson, et al., 2009).

Ho (Ho, 2008) descreve que a modificao realizada na rvore B+
para permitir operaes do tipo append. Todas as atualizaes (criao,
alterao e remoo de documentos) so realizadas atravs de um append,
onde ao invs de modificar documentos existentes, uma nova cpia do
documento criada e os dados so adicionados regio relacionada. Em
seguida, a rvore B+ alterada para apontar para a nova verso ou o novo
documento. Esta atualizao dispara a atualizao do n superior (pai) ao n


21


que est sendo atualizado, que em seguida realiza a mesma atualizao no
seu pai, seguindo assim at a raiz da rvore, onde ir modificar o seu
cabealho para apontar para o novo n raiz. O autor observa que todas as
atualizaes disparam somente uma operao de escrita ao documento (com
exceo da remoo) e escritas para cada n da rvore B+, o que
resulta em complexidade para operaes de append.

Uma outra vantagem de somente utilizar operaes de append est no
uso do modelo MVCC. Segundo o autor, o arquivo de dados mantm sempre
um histrico de todas as verses prvias de um documento. Se um cliente
mantiver o acesso a um n raiz anterior ao atual da rvore B+, operaes de
atualizao podem ser realizadas continuamente na rvore no servidor, sem
que o cliente veja estas atualizaes. Esta consistncia de snapshot muito
til em backups online e compactao online.

2.2.5.2 Ausncia de Bloqueios

Anderson e outros (Anderson, et al., 2009) observam que para garantir
a consistncia dos dados, um SGBDR deve restringir as operaes a somente
uma atualizao de dados em uma tupla por vez, e que ningum poder ler
aquela tupla enquanto uma atualizao estiver sendo efetuada. A figura 2.1
mostra como realizado o processo de bloqueio em uma transao relacional,
onde h a serializao de execuo de requisies. Os autores explicam que
quando h uma requisio de atualizao, concedido ao cliente acesso ao
recurso, enquanto este bloqueado para leitura e outras escritas. Desta forma,
quando um cliente for ler os dados, estaro vendo a ltima verso dos valores
requisitados.



22




Figura 2.1. Exemplo de bloqueio em uma transao relacional. Quando h uma operao
de escrita, todas as leituras aguardam at que esta escrita finalize para prover uma
verso consistente do dado. Fonte: (Anderson, et al., 2009).

Nos BDODs, por utilizarem o conceito de versionamento de
documentos e no utilizarem bloqueios, as escritas e leituras so feitas de
forma paralela, o que, segundo os autores, aumenta a capacidade de atender a
mais requisies por segundo, pois no h espera por parte dos usurios para
a leitura de dados.


Figura 2.2 Exemplo de transao em um BDOD. O modelo MVCC permite que leituras e
escritas sejam feitas de forma paralela, permitindo que o CouchDB utilize o poder de
processamento de um servidor por completo. Fonte: (Anderson, et al., 2009).

2.2.6 Implementao

Esta seo aborda o Erlang OTP, a plataforma na qual o CouchDB foi
construdo e tambm o JavaScript Object Notation (JSON), a notao utilizada
pelo banco para representao de estruturao de dados.

escrita
T0
T1: leitura 1
T2: leitura 2
Tn-1: leitura n
Tn
commit
leitura
seqencial
leitura
seqencial
escrita
seqencial
leitura
seqencial
verso antiga
verso nova


23


2.2.6.1 Erlang

Erlang uma linguagem de programao que possui muitas
caractersticas comumente associadas com as de um sistema operacional,
como o processamento concorrente, scheduling, gerenciamento de memria,
distribuio, networking, entre outras. Construda para sistemas de
telecomunicao em tempo real, o Erlang possui forte nfase na execuo em
ambientes distribudos. Cada mquina virtual Erlang tambm chamada de n
e cada n pode criar processos paralelos em outros ns, onde a comunicao
entre os processos se d de forma nativa na linguagem (Erlang, 2009).

O CouchDB foi projetado para atender a requisies de leitura e escrita
como em um ambiente livre de concorrncia. O Erlang compartilha as mesmas
premissas arquiteturais do CouchDB, permitindo que haja a reduo de
gargalos, e tornando o trabalho do sistema previsvel sob forte carga de dados
por no utilizar bloqueios de escrita e gravao (Apache CouchDB, 2008).
2.2.6.2 JavaScript Object Notation

O JSON um padro leve de intercmbio de dados, projetado para
facilitar a leitura e escrita de estruturas, tambm sendo de fcil interpretao e
gerao por mquinas. Suas estruturas so baseadas em um subconjunto da
especificao da linguagem JavaScript, definida em (ECMA, 1999), e permitem
a construo de estruturas de dados partindo de dois conceitos: uma coleo
de pares chave/valor e uma lista ordenada de valores (JSON, 2008).

Composta de seis estruturas elementares, o JSON utilizado pelo
CouchDB como forma padro de armazenamento de dados (Apache CouchDB,
2008). A listagem abaixo apresenta como so construdas as estruturas
elementares do JSON, no que tange aos elementos de sua gramtica, como
definidos em (JSON, 2008):

Objeto: sua representao feita atravs de chaves. Exemplo:
{} ou { membros };


24


Pares: so os pares chave/valor, definidos como uma string e
um valor. Exemplo de uma expresso: nome : Leonardo
Eloy;
Membros: Um ou mais pares de chave/valor;
Array: so listas de elementos, podem ser multidimensionais.
Exemplo: [ { chave: valor }, 1234 ] array de um
par e um valor, ambos so elementos;
Valor: so os tipos de dados que o JSON pode assumir: string,
numrico, objeto, array, true, false ou null.

2.2.7 Administrao

A administrao do CouchDB pode ser realizada por diversas APIs
REST, que possuem implementaes em Ruby, Python e Java, mas tambm
pela interface de administrao que fornecida juntamente com o banco de
dados, chamada Futon. O Futon uma aplicao que funciona exclusivamente
com um browsers que sejam capazes de interpretar JavaScript e realizar
consultas atravs de requisies assncronas com JavaScript utilizando a
tecnologia Ajax (Asynchronous Javascript And XML). Como o browser
implementa o protocolo HTTP, este tambm capaz de manipular documentos
em um banco de dados CouchDB atravs dos mtodos GET, PUT, POST e
DELETE (como descrito no captulo 4) (Lennon, 2009). A figura 2.3 mostra a
tela do Futon exibindo a listagem de documentos em um banco de dados
chamado blog.



25



Figura 2.3. Interface do Futon, uma aplicao de gerenciamento embutida no CouchDB.


2.3 Comparativo Relacional e Orientado a Documentos

Na seo anterior foi apresentado o CouchDB, uma implementao de
referncia de um BDOD e o funcionamento de seus principais. Nesta seo
apresentado um comparativo entre os BDODs e SGBDRs, no que concerne s
principais caractersticas de ambos os sistemas.

2.3.1 Modelagem de Dados

Segundo Anderson e outros (Anderson, et al., 2009), BDODs utilizam o
conceito de dados e documentos autocontidos e autodescritivos, isso implica
que o documento em si j define como ele deve ser apresentado e o significado
dos dados em cuja sua estrutura esto armazenados. Os autores explicam que
o conceito de dados autocontidos ajudam a entender como se d a modelagem
orientada a documentos e utilizam o exemplo de uma nota fiscal para mostrar
como funcionam os documentos no mundo real. Em um documento fiscal,
todas as informaes sobre uma transao j esto l contidas: nome do
tomador do servio, dados do prestador do servio, data de prestao, servios
efetuados, entre outras. Como mostrado figura 2.4, no h nenhuma referncia


26


abstrata para um outro pedao de papel que indique o nome do prestador do
servio ou o nome os itens que compem aquela nota fiscal. Mesmo assim,
esta a forma como os dados so armazenados em um banco de dados
relacional: cada nota fiscal gravada em uma tabela tal que suas tuplas
referenciem outras tuplas em outras tabelas, onde teramos uma tupla para as
informaes do prestador de servio, uma para o tomador do servio, outra
para cada item cobrado e assim por diante. Os autores deixam claro que
muitas vezes a forma como o modelo deve ser projetado, de acordo com seu
paradigma, muitas vezes no refletem a forma como um desenvolvedor
gostaria de ter seus dados armazenados.

A forma como os dados so modelados em BDODs permitem que haja
redundncia e inconsistncia dos dados, sem que haja nenhuma camada
semntica para permitir o acesso a uma nica verso de um dado.

Mais adiante, Anderson e outros (Anderson, et al., 2009) descrevem
um segundo exemplo (figura 2.5) que ilustra uma forma diferente de
modelagem de dados: uma pilha de cartes de visita. Da mesma forma que
uma nota fiscal, um carto de visita contm todas as informaes importantes
em um nico documento. A maioria dos cartes de visita contm as mesmas
informaes: a identificao de uma pessoa, sua afiliao e informaes de
contato. A diferena principal que o carto de uma pessoa A pode conter o
nmero do seu telefone celular, enquanto de uma pessoa B, somente seja
informado um telefone fixo. Como a pessoa B no informou o nmero de um
telefone celular, ela no tem a necessidade de tornar isso explcito, escrevendo
no carto algo como Telefone Celular: nenhum. Ao invs, por simplesmente
omitir esta informao, a pessoa j est declarando que no possui um contato
deste tipo disponvel.



27



Figura 2.4 Modelo de uma nota fiscal. Para os BDODs, a modelagem de dados deve
seguir o conceito natural dos dados, onde todas as informaes j esto contidas no
documento. Fonte: (Domnio Contabilidade, 2008).




28



Figura 2.5. Cartes de visita, onde a mesma informao declarada, mudando somente a
forma como os dados so estruturados. As informaes destacadas em vermelho
mostram como as diferenas de estrutura dos cartes.

Neste sentido, os autores observam que documentos do mundo real
tendem a variar de forma similar na semntica dos dados, ou seja, o tipo de
informao que estes documentos apresentam. Porm, a sintaxe com a qual as
informaes so apresentadas, ou seja, sua estrutura, pode variar
enormemente. Em face ao exposto, os autores concluem que enquanto num
modelo relacional tradicional necessrio que os dados estejam modelados
antes de serem utilizados, em um BDOD livre de esquema, os documentos
esto prontos para agregarem informaes aps serem criados, exatamente da
mesma forma como feita com os documentos do mundo real. Desta forma, os
documentos esto preparados para a evoluo natural dos dados. Esta
evoluo pode ser exemplificada quando uma pessoa com um carto de visitas
risca um nmero desatualizado e escreve a informao mais atual, evoluindo
os dados do documento.

2.3.2 Estado Global de Recursos

Anderson e outros (Anderson, et al., 2009) afirmaram que durante o
processo de modelagem relacional, uma das premissas a identificao nica
de registros. Os autores estabelecem que uma chave natural a coleo de
colunas que identificam uma tupla como nica dentro de uma tabela e que uma
forma de facilitar a criao de chaves nicas em uma tupla, ao invs da
utilizao de chaves naturais est na atribuio de um identificador numrico
nico para cada tupla. A maioria dos bancos de dados relacionais prov


29


estruturas chamadas de sequences, que podem atribuir automaticamente estes
identificadores numricos a uma tupla.

Segundo os autores, o principal problema das sequences que elas
representam um estado global compartilhado, ou seja, a fim de atribuir um
identificador numrico para uma tupla, a obteno do valor desta entidade deve
ser realizada de forma seqencial, com um nico acesso por vez. Isso se torna
um problema quando h dois bancos de dados em redes distintas que
necessitam realizar uma atualizao concorrente de dados, pois no h uma
forma de ambos os bancos saber em qual ser o prximo valor a ser atribudo.
Neste sentido, os autores definem o conceito que em uma arquitetura sem
nada compartilhado (shared-nothing architecture) no h um estado ou valor
prximo, pelo fato que nenhum estado global armazenado entre os bancos,
ou seja, cada instncia toma decises baseadas somente no seu estado atual.

Para contornar o problema das sequences, os BDODs podem utilizar o
conceito de Universally Unique Identifiers (Identificadores nicos Universais, ou
somente UUID), onde Anderson e outros (Anderson, et al., 2009) observam
que a possibilidade de acidentalmente utilizar um mesmo identificador que
outro banco de dados efetivamente zero.

Os UUIDs so atribudos como identificadores do documento, que
devem ser nicos dentro de um BDOD. Caso o usurio ache necessrio atribuir
uma chave natural a um documento, ele deve utilizar campos especficos e
armazen-los dentro do documento.

No que concerne a melhorias em relao aos bancos de dados
relacionais, o conceito de UUID no apresenta muita utilidade. Os autores
sugerem que o importante entender que em BDODs no ser necessrio
consultar os documentos atravs de um identificador, j que estes oferecem
mtodos avanados de agrupamento e filtragem de documentos baseado em
seu contedo, atravs das views e do MapReduce, explicados na seo 2.2 e
detalhados no captulo 3.



30


2.3.3 Propriedades Arquiteturais

Pelo fato de utilizar um modelo arquitetural RESTful (baseado no
REST, como mostrado no captulo 4) e por este utilizar o protocolo HTTP e o
paradigma da Web como base (Fielding R. T., 2000), a escalabilidade de um
BDOD uma conseqncia da sua utilizao. Anderson e outros (Anderson, et
al., 2009) listaram propriedades derivadas deste modelo arquitetural que
tornam a utilizao de BDODs apta a suportar a necessidade de expanso do
seu servio:

Cliente/Servidor: a diviso entre clientes e servidores facilita na
separao da complexidade de desenvolvimento necessria
para construo de ambos. Os autores afirmam que clientes
podem ser adaptados para diferentes ambientes e componentes
podem evoluir de forma independente dos outros;
Sem Estado (Stateless): quando um servio armazena dados
de um cliente entre requisies subseqentes, diz-se que o
servidor est mantendo um estado para cada cliente. Ao forar
que o cliente gerencie o estado, o servidor pode diminuir o
excesso de processamento envolvido nas operaes de
manuteno de estado, resultando em tempos de resposta mais
rpidos. Os autores afirmam ainda que sem a necessidade de
manter estados entre requisies possvel distribuir tarefas
entre diferentes servidores para balancear a carga de
processamento nos mesmos;
Armazenveis (Cacheable): quando operaes levam muito
tempo para finalizar e consumir poder de processamento, o
armazenamento de resultados entre requisies pode
significativamente melhorar o desempenho do sistema. No
HTTP, a funcionalidade de armazenamento (cacheing) j est
embutida em nvel de protocolo, o que permite a eliminao
parcial ou completa de interao com o servidor para algumas
requisies. Segundo os autores, o CouchDB fornece um


31


cabealho especfico para armazenamento chamado Etag, o
que permite identificar o documento envolvido em uma
requisio. Isto permite que quando um cliente requisita o
documento, ao invs de envi-lo novamente para o cliente, o
BDOD informa somente que o cliente j possui a ltima verso,
no havendo necessidade de transporte desnecessrio e dados;
Interface Uniforme: o vocabulrio imposto pelo REST permite
que qualquer sistema que implemente o protocolo HTTP possa
se comunicar com o BDOD, promovendo, desta forma, o
desacoplamento do servidor com o cliente. A identificao de
recursos feito atravs de um Uniform Resource Identifier
(Identificador Uniforme de Recurso, ou somente URI), que
descrito no captulo 4.

A norma ISO/IEC 9075-1:2008 (International Organization for
Standardization, 2008) define a linguagem SQL, inclusive estabelecendo um
critrio mnimo de adoo para tornar a linguagem universal. Porm, os
diversos fabricantes de bancos de dados estendem a linguagem SQL, criando
dialetos prprios (Arvin, 2009), o que faz com que a eficcia universal do SQL
esteja somente no nvel mnimo que a norma define.

Os SGBDRs tambm utilizam as propriedades citadas, como a
utilizao de uma arquitetura cliente/servidor e o fato de no manterem o
estado de sesso entre requisies de um cliente.

2.3.4 Junes

Anderson e outros (Anderson, et al., 2009) observam que muitas
atividades podem ser realizadas por um SGBDR. Citando o exemplo das notas
fiscais da seo 2.3.1, o usurio pode requisitar ao banco todas as notas fiscais
cuja coluna valor seja maior que R$ 100. O conceito de chave estrangeira
pode ser explorado atravs da obteno de todos os tomadores de servios de


32


notas fiscais. A tarefa que realiza a unio destes dois valores conhecida
como juno.

Os BDODs no suportam chaves estrangeiras como na forma
tradicional, mas operaes de juno podem ser realizadas aps a agregao
de dados em documentos utilizando o conceito de views, apresentado no
captulo 3. Com uma view possvel criar relacionamentos um-para-um, um-
para-muitos e muitos-para-muitos, assim como num banco de dados relacional.
Views tambm permitem a criao de estruturas de dados mais complexas,
como rvores. A linguagem SQL no prov suporte a criao deste tipo de
estrutura.

2.4 Consideraes Finais

O CouchDB um sistema distribudo, acessvel atravs de uma API
RESTful, realiza o armazenamento versionado de objetos que utiliza a
abstrao de documentos, disponibiliza uma forma de agregar e consultar
dados atravs do MapReduce e replica seus dados de forma incremental, bi-
direcional e multi-master, utilizando o MVCC, um algoritmo de consenso de
conflitos, onde os dados esto sujeitos a consistncia eventual em cada n
(Anderson, et al., 2009).

O projeto Apache CouchDB ainda est nos seus estgios iniciais e a
verso mais atual do software (denominada 0.9) ainda considerada alfa
(software que ainda no est pronto para produo). Apesar disso, aplicaes
como wikis, blogs, fruns de discusso e sistemas de gerenciamento de
documentos tm evitado a utilizao de SGBDRs a fim de tornar-se cada vez
mais eficientes no que concerne ao gerenciamento de reviso de documentos
e a contnua mudana de requisitos de esquema de dados, e utilizam o
CouchDB em suas aplicaes (Lennon, 2009).

Bancos de Dados Relacionais definem uma estrutura rgida a fim de
prover a manuteno de consistncia de dados para uma aplicao. Os


33


BDODs oferecem uma nova forma de armazenamento dos dados, referenciada
como livre de esquema, por permitir o armazenamento de dados de forma
semi-estruturada, ainda fornecendo mecanismos de tornar estes dados
acessveis e manipulveis, sendo construdos especificamente no contexto da
Web (Lennon, 2009). Em despeito a sua abordagem diferenciada em relao
ao armazenamento, consulta e distribuio de dados, os BDODs no
substituem os SGBDRs, apenas realizam tarefas especficas de forma mais
eficiente, como o armazenamento versionado de objetos.



34





Captulo 3 Recuperao de Dados
3.1 Introduo

Neste captulo vamos abordar como o CouchDB, uma implementao
de um banco de dados orientados a documentos (BDODs), utiliza o modelo de
programao MapReduce para recuperar os dados armazenados. O
MapReduce uma tecnologia utilizada pelo Google para realizar operaes
sobre um grande conjunto de dados de forma paralela (Dean & Ghemawat,
2004a). Tambm apresentado como so implementadas as views no
CouchDB e como se d o processo de consulta utilizando o MapReduce.

3.2 MapReduce

A pesquisa para constituir o MapReduce iniciou-se com a necessidade
de criao de uma estrutura de processamento de grandes volumes de dados,
como logs de requisio de pginas da Web, documentos obtidos na web e
outros dados brutos. As premissas bsicas para um algoritmo de
processamento deste porte eram a alta escalabilidade, possibilidade de
utilizao de hardware commodity, ou seja, mquinas acessveis para o
consumidor final, ao invs de mquinas com grande poder de processamento e
a possibilidade de dividir o poder computacional entre diversos ns distintos
(Dean & Ghemawat, 2004a).

O MapReduce um modelo de programao para processamento de
um grande conjunto de dados. Dean e Ghemawat (Dean & Ghemawat, 2004a)
apresentaram seu modelo que consiste na especificao de uma funo de
mapeamento (map), que processa um conjunto de pares chave/valor para
gerar um conjunto intermedirio de chave/valor. Neste conjunto intermedirio,


35


uma segunda funo de reduo (reduce), e apliacada mesclando todos os
valores intermedirios com uma mesma chave intermediria (figura 3.1). De
fato, a funo de reduo agrupa estes valores intermedirios a fim de prover
um resultado para a consulta, como exemplificado na seo 3.1.1.


Figura 3.1. O processo de execuo do MapReduce, onde as entradas recebem uma
funo para criao de um valor intermedirio (M de map). J estes valores sofrem uma
reduo (R de reduce) atravs de uma segunda funo, criando o conjunto de dados que
representam o resultado.. Fonte: (Dean & Ghemawat, 2004b).

DeWitt e Stonebraker (DeWitt & Stonebraker, 2008) observaram que o
modelo consiste em dois programas chamados de map e reduce, alm de um
framework para execuo de instncias destes programas em um cluster de
computadores. O primeiro programa (map) l dados de entrada, realiza
transformaes e filtragens necessrias sobre o conjunto de dados e ento
expe estes dados no formato de chave/valor. O segundo programa (reduce)
divide os registros intermedirios em buckets desmembrados, por aplicar uma
funo na chave de cada registro processado. Podemos considerar a funo
de reduce como determinstica, pois seu resultado ser sempre o mesmo para
um mesmo par chave/valor de entrada, portanto, seu comportamento anlogo
a uma funo hash. O programa finaliza com M buckets de sada preenchidos
(DeWitt & Stonebraker, 2008).



36


3.2.1 Crticas

Diversas crticas foram feitas sobre o modelo do MapReduce em
(DeWitt & Stonebraker, 2008), como a argumentao que o MapReduce um
algoritmo de fora bruta, por no utilizar ndices para realizar suas buscas.
Outras crticas envolvem a questo de no possuir as principais caractersticas
j disponveis em SGBDRs modernos, como transaes, integridades
referenciais, updates (como apresentado no captulo 2, um update uma nova
verso do conjunto de dados), ndices e um bulk loader para dados.

Jorgensen (Jorgensen, 2008) criticou fortemente as colocaes de
DeWitt e Stonebreaker, declarando que o MapReduce no um sistema de
banco de dados, por isso no sua tarefa implementar os conceitos de tal
sistema. O autor argumenta que o MapReduce, para certos tipos de
aplicaes, como o processamento de um grande conjunto de dados de logs
de acesso ou pginas web, no ir garantir a integridade de 100% dos dados,
que de fato estes sistemas fazem com maestria. Porm, o MapReduce ajuda
no processamento desta informaes por possuir uma arquitetura pronta para
paralelizar o processamento em pequenas unidades de trabalho.

Chu-Carrol (Chu-Carrol, 2008) tambm respondeu s crticas feitas por
DeWitt e Stonebraker frisando que um SGBDR dificilmente pode dividir uma
tarefa entre 1.000 ns de um cluster feito com computadores baratos.
Observou tambm que o modelo do MapReduce no foi construdo para
mimetizar o modelo relacional, sendo esta uma outra tcnica para atingir
objetivos em problemas que um SGBDR realizaria com emprego de muitos
recursos por vezes desnecessrios.

DeWitt e Stonebraker (DeWitt & Stonebraker, MapReduce II, 2008)
responderam s crticas atestando que no comparam a tcnica com um
sistema de banco de dados. Os autores exemplificaram um conjunto de dados
de pginas da web com um ranking de acesso e outro conjunto com dados de
acesso a essas pginas. Com estes exemplos, os autores demonstram que o


37


SQL pode ser utilizado de forma eficiente para obter dados, pois o MapReduce
no prov suporte a junes. Novas crticas surgiram deste segundo artigo,
onde Rotem (Rotem, 2008) diz que um problema de MapReduce no pode ser
definido na tica um SGBDR, pois este modelo de programao no foi
projetado para ser um sistema de banco de dados e que de fato este problema
no pode ser solucionado de forma eficiente pela arquitetura. Ramon ainda
completa dizendo que empresas estabelecidas como Google, Amazon e eBay
no utilizam transaes ou bancos de dados distribudos, e sim a tcnica de
sharding, que consiste no particionamento de tuplas atravs de diferentes
mquinas ou localizaes fsicas (Roy, 2008).

3.2.2 Outras Utilizaes

Este modelo de programao tambm utilizado em frameworks de
processamento paralelo de informaes. Nesta seo sero mostrados dois
exemplos de frameworks open source: Hadoop e Hive Framework.

3.2.2.1 Hadoop

O Hadoop um framework Java que permite a utilizao de milhares
de ns para o processamento de dados distribudos na ordem dos petabytes,
provendo confiabilidade e mobilidade de dados. Atravs do MapReduce, a
aplicao divida em pequenos fragmentos de trabalho, que podem ser
executados ou re-executados em ns de um cluster de hardware commodity.
Alm disso, prov um sistema de arquivos distribudo que realiza o
armazenamento de dados nos ns computados, provendo um alto valor de
largura de banda agregada dentro do cluster (Apache Hadoop, 2007).

O framework pode ser utilizado atravs da API JDBC (Java Database
Connectivity), que permite a comunicao com bancos de dados. Desta forma,
o Hadoop pode ser utilizado como um SGBDR, apesar de no prover as
caractersticas essenciais deste tipo de sistema, como ndices, transaes,
updates, entre outras.


38



3.2.2.2 Hive Framework

Este framework foi construdo utilizando o Hadoop, prov um abstrao
relacional para o conceito do MapReduce, possibilitando a consulta de dados
utilizando o SQL. Utilizado na empresa Facebook, a arquitetura possibilita a
consulta de milhes de tuplas em um cluster de hardware commodity (Sarma,
2008).

3.3 Views

A seguir apresentado como o MapReduce pode ser utilizado para
realizar consulta em BDODs, atravs de uma estrutura chamada view. Na
seo anterior foi apresentado o MapReduce, um modelo de programao que
ajuda na diviso de tarefas atravs de duas funes distintas: o mapeamento,
que obtm registros gerando valores intermedirios, e a reduo, que agrupa
estes registros resultando numa sada para a consulta. Este modelo utilizado
no CouchDB para a realizao de consultas de dados atravs de uma estrutura
intermediria chamada de view (Anderson, et al., 2009).

Para o CouchDB, as views so uma ferramenta primria para
consultas e relatrios de documentos (Apache Group, 2009). Para estabelecer
um paralelo entre os SGBDRs, Murphy (Murphy, 2008) compara as views de
um BDOD com tabelas de um banco relacional.

Imagine diversas tabelas em um banco de dados, cada uma com
colunas diferentes. Agora imagine que todas as tuplas de cada uma
destas tabelas somente um documento no CouchDB, todas
associadas a um mesmo bucket (banco de dados) e sem qualquer
hierarquia. As views so o que filtram e agregam os documentos para
criar (numa forma muito limitada) o equivalente a uma tabela
(Murphy, 2008).



39


Anderson e outros (Anderson et al., 2009) observam que as views tm
funes bastante objetivas a serem desempenhadas em BDODs:

Extrao de dados de documentos que so necessrios para um
propsito especial, em uma ordem especfica;
Construo de ndices eficientes para encontrar documentos por
qualquer valor ou estrutura que um documento possua;
Utilizar estes ndices para representar relacionamentos fracos entre
documentos;
Realizar todos os tipos de clculos nos dados contidos nos
documentos. Por exemplo, uma view pode responder a perguntas
como quanto foi o gasto da uma empresa na ltima semana, ms
ou ano.

Os autores observam que o CouchDB trabalha com diversos servidores
de views. Em essncia, isso significa que o CouchDB prov uma estrutura de
interfaces, onde diversos servidores de view podem ser ligados, possibilitando
ao usurio a utilizao de uma linguagem especfica para construo de views.
Por padro, o CouchDB utilizao a linguagem JavaScript para criao de
views.

3.3.1 Exemplos

Para compreender melhor o funcionamento das views juntamente com
o MapReduce, um conjunto de dados de exemplo e trs funes de
mapeamento e reduo so apresentados a seguir. Nestes exemplos utilizam-
se um conjunto de dados de um sistema de gerenciamento de um blog,
aplicao que funciona como um dirio, acessvel atravs da Web. Esta
aplicao possui um conjunto simples e limitado de entidades. Um blog possui
um autor e cada autor pode realizar diversos posts (postagens), que consistem
em um texto com um ttulo. Cada post poder ter diversos comentrios, que
so armazenados como o nome e uma mensagem de comentrio. O fluxo de
utilizao da aplicao exemplificado na figura 3.2.


40



A modelagem de dados orientada a documentos deve levar em
considerao a relao entre os contedos que compe um texto, dividindo
estas relaes em composies de atributos. A figura 3.3 mostra esta
abstrao representada visualmente.


Figura 3.2. O fluxo de utilizao de um sistema de blogs. O autor realiza um post e
diversas pessoas podem emitir comentrios neste post.

Para este exemplo, os documentos mostrados na listagem 3.4 sero
utilizados. Nesta listagem pode-se perceber atravs da notao JSON (como
apresentado no captulo 2) a hierarquia entre os pares de chave/valor que
compem o documento. Em ambos os registros, pode ser percebida a
utilizao de um array para agrupamento de comentrios. Dentro de cada
array, objetos que aninham as chaves que representam um comentrio so
representados entre colchetes.

- auLor
8log
- uLulo
- corpo
- daLa
osL
- nome
- LexLo
- daLa
ComenLrlo


41




Figura 3.3. Representao de um blog como um documento. Cada post realizado na
pgina leva atributos como ttulo, autor e corpo do texto. Para cada postagem, usurios
podem realizar comentrios, como em um documento de papel, este usurio assina seu
comentrio e indica em qual data foi realizado.


Documento A

{
"titulo": "Este um post no blog",
"autor": "Leonardo Eloy",
"data": "21/04/2009 20:38:00",
"corpo": "Hoje eu realizei um monte de coisas... ",
"comentarios": [
{
"nome": "Josias Cabelo",
"texto": "Gostei muito do seu post!",
"data": "28/04/2009 12:31:09"
},
{
"nome": "Fulano de Tal",
"texto": "Muito interessante, continue",
"data": "29/04/2009 13:17:31"
}
]
}


Documento B

{
"titulo": "LOLcats em alta",
"autor": "Leonardo Eloy",
Muito legal seu blog!
por Josias Cabelo em
13/06/2009.
Aguardo o prximo
post!
por Josias Cabelo em
18/06/2009.
Espero sucesso.
por Fulano de Tal em
24/05/2009.
!"# %&'()(*+&
uaLa: 12/06/2009, por Leonardo Lloy

Po[e eu flz lsso e aqullo...
2 comenLrlos
,-(."(-& ,&/'
uaLa: 23/03/2009, por Leonardo Lloy

Lsse e o meu prlmelro...
1 comenLrlo


42


"data": "31/05/2009 04:31:13",
"corpo": "A credibilidade em documentos crtica...",
"comentarios": [
{
"nome": "Josias Cabelo",
"texto": "Mais uma vez, superao!",
"data": "08/06/2009 23:49:38"
}
]
}

Listagem 3.4. Exemplo de dois documentos que representam posts em um blog,
exibidos aqui utilizando a notao JSON.

Como j discutido neste captulo, o MapReduce consiste em duas
funes: uma de mapeamento e outra de reduo. O mapeamento ir
transformar as chaves armazenadas em valores intermedirios, e a reduo ir
obter estes valores e retornar um resultado. Com a execuo deste processo,
dois tipos de funes MapReduce sero projetadas a fim de obter os resultados
para as seguintes consultas: quantidade de posts por autor e a listagem de
posts por autor.

3.3.1.1 Consulta Um: Quantidade de Posts por Autor

necessrio obter todas as chaves que representam o valor autor de
um post no blog. Portanto, a funo de mapeamento ter que criar chaves
intermedirias com o nome do autor. A funo de reduo ir obter as chaves
com o nome do autor e realizar uma soma da quantidade de chaves. Desta
forma, a funo de mapeamento dever gerar chaves intermedirias com o
nome do autor e como valor utilizar o inteiro fixo 1, pra que este seja somado
pela funo de reduo.

1 function map(doc) {
2 if (doc.autor) emit(doc.autor, 1);
3 }
Listagem 3.5. Funo de mapeamento para emisso de chaves intermedirias
preparadas para serem somadas durante a fase de reduo.

Na linha dois, caso o documento possua a chave autor, a funo de
mapeamento ir emitir, ou seja, cadastrar como chave intermediria o valor que


43


est contido dentro da chave autor, atribuindo-lhe o valor 1. Desta forma, as
chaves intermedirias estaro como na listagem 3.6. possvel perceber que
existem dois registros com o mesmo valor, isso aconteceu por que o
MapReduce foi executado para os documentos A e B (como na listagem 3.4), e
para cada documento uma chave intermediria foi criada.

[
{
"Leonardo Eloy": 1
},
{
"Leonardo Eloy": 1
}
]
Listagem 3.6. Chaves intermedirias geradas partir da chamada da funo de
mapeamento mostrada na listagem 3.5.

Aps a execuo da funo de mapeamento, o CouchDB ir chamar a
funo de reduo, passando duas variveis: as chaves que foram emitidas e
os valores de cada chave. Para cada conjunto de chaves, um nico valor ser
emitido.

1 function reduce(keys, values) {
2 return sum(values);
3 }
Listagem 3.7. Funo de reduo que obtm as chaves e os valores intermedirios
gerados pela funo de mapeamento (listagem 3.5).

{
"rows": [
{
"key": "Leonardo Eloy",
"value": 2
}
]
}
Listagem 3.8. Resultado da sada da funo de reduo (listagem 3.7).

A listagem 3.8 mostra o resultado da execuo das funes de
mapeamento e reduo. A consulta foi saber a quantidade de posts por autor.
O nome do autor estar contido na chave (key) e a quantidade de posts est no
valor (value) desta chave. A listagem 3.9 mostra o resultado final da execuo
do processo de MapReduce para esta consulta.



44



Listagem 3.9. Sumrio final da execuo do processo de MapReduce.

3.3.1.2 Consulta Dois: Listagem de Posts por Autor

O objetivo desta consulta listar o ttulo e a data de um post para cada
autor. A funo de mapeamento dever emitir o nome do autor como chave e o
ttulo e a data do post como valor.

1 function map(doc) {
2 if (doc.autor) emit(doc.autor, {titulo: doc.titulo, data:
doc.data});
3 }
Listagem 3.10. Funo de mapeamento para emisso de chaves intermedirias
preparadas para serem somadas durante a fase de reduo.

A execuo da funo de mapeamento resulta num conjunto de chaves
intermedirias que extraem o ttulo e a data de cada post realizado por um
autor. A listagem 3.11 mostra os resultados da execuo deste procedimento.

{
"Leonardo Eloy": {
"titulo": "LOLCats em Alta",
"data": "31/05/2009 04:31:13"
},
"Leonardo Eloy": {
"titulo": "Este um post no blog",
"data": "21/04/2009 20:38:00"
}
}
Listagem 3.11. O resultado da execuo da funo de mapeamento, agrupando o ttulo e
data de um post por autor.

Aps a obteno das chaves intermedirias, o objetivo agrupar o
valor das chaves (um objeto composto por ttulo e data) para cada chave. Esta
tarefa facilmente declarada utilizando JavaScript, como na listagem 3.12.





45


1 function reduce(keys, values) {
2 return values;
3 }
Listagem 3.12. Funo de mapeamento para emisso de chaves intermedirias
preparadas para serem somadas durante a fase de reduo.

Depois de realizada a reduo, o resultado da consulta retornado,
como visto na listagem 3.13. Na listagem 3.14 apresentado um sumrio de
execuo desta consulta utilizando MapReduce.

{
"rows": [
{
"key":"Leonardo Eloy",
"value":[
{
"titulo":"LOLcats em alta",
"data":"31/05/2009 04:31:13"
},
{
"titulo":"Este um post no blog",
"data":"21/04/2009 20:38:00"
}
]
}
]
}
Listagem 3.13. Resultado final da consulta, aps a execuo da funo de reduo.


Listagem 3.14. Sumrio da execuo das funes de mapeamento e reduo.

3.4 Consideraes Finais

Neste captulo foi apresentado o MapReduce, uma tcnica de
programao utilizada para recuperao de dados e tambm para facilitar o
processamento paralelo de um grande volume de dados por Bancos de Dados
Orientados a Documentos. Atravs do MapReduce, o CouchDB implementa o


46


conceito de view, onde um usurio pode criar um programa de mapeamento e
outro de reduo para filtrar e agregar dados de uma base de documentos.

Foi utilizado um sistema de blog para exemplificar como se d a
modelagem de sistemas orientados a documentos: partir de como funciona
uma aplicao, foram derivados os nveis de dados que so necessrios para
compor o documento, no caso do blog, a maior unidade de informao o
post, que concentra diversos comentrios e possui um ttulo e o corpo do texto.

Foram apresentados exemplos que ilustram diversos tipos de consultas
realizadas na base de documentos do blog atravs das views. Estas consultas
utilizam a tcnica MapReduce e a programao em JavaScript, linguagem
internamente utilizada no CouchDB para definio de estruturas (Anderson, et
al., 2009). Acreditamos que atravs do MapReduce um problema pode ser
dividido entre diversos ns para processamento paralelo de forma eficaz, ao
permitir a utilizao de funes que permitem que um programador utilize mais
recursos para definir os dados que deseja retornar em uma consulta.


47





Captulo 4 Interface de Consultas
4.1 Introduo

Da mesma forma que os SGBDRs oferecem o SQL como interface de
consulta (Silberschatz, et al., 2006), o CouchDB oferece uma interface de
consultas adaptada aos seus princpios arquiteturais baseados na Web,
atravs do Representational State Transfer (REST), que utilizado como forma
de inserir, atualizar, extrair e remover dados do CouchDB (Anderson, et al.,
2009).

Neste captulo demonstrado como funciona o princpio arquitetural
REST, seus conceitos de recursos e mtodos padronizados, como o CouchDB
trabalha com o REST, suas vantagens, desvantagens e exemplos de como
selecionar dados utilizando este modelo arquitetural.

4.2 REST

Fielding (Fielding R. T., 2000) concebeu a idia do REST em sua tese
de doutorado, que trata dos estilos arquiteturais dos softwares projetados para
trabalharem em rede. O autor define REST como sendo um conjunto de
princpios arquiteturais que quando aplicadas como um todo, enfatiza a
escalabilidade da interao entre componentes para reduzir a latncia de
interao, garantir segurana e encapsular sistemas legados. Fielding trata a
interao entre componentes como sendo uma estilo cliente-servidor
estruturado em camadas, onde estas camadas so estruturas de requisio
(request) e reposta (response) que tm a aparncia de um estilo de invocao
remota, mas, no conceito do REST, estas mensagens so de fato enviadas a
um recurso conceitual ao invs de uma implementao de fato. Fielding


48


tambm cunhou o termo RESTful, que identifica um sistema que adere aos
princpios arquiteturais por ele descritos.

Tilkov (Tilkov, 2007) apresenta o REST como sendo um conjunto de
princpios que definem como os padres Web, como o HTTP e URIs devem ser
utilizados. O autor destaca que o REST trabalha de uma forma particular,
diferente de como se costuma trabalhar com a tecnologia HTTP e o conceito de
URI. Tilkov conclui dizendo que a principal promessa do REST que se voc
aderir aos princpios durante o projeto de sua aplicao, voc ir acabar com
um sistema que explora a arquitetura Web em seu benefcio.

Fielding (Fielding R. T., 2000) classificou em o REST nos seguintes
princpios:

1. Cliente-Servidor: a separao permite que os componentes
evoluam independentemente, apoiando assim um requisito de nvel
de Internet para mltiplas organizaes;
2. Sem Estado: cada requisio de um cliente ao servidor deve
conter todas as informaes necessrias para entender a
requisio;
3. Cache: limitaes de cache necessitam que os dados dentro de
uma resposta a uma requisio estejam implcitos ou
explicitamente identificados como passveis de cache (cacheable)
ou no (non-cacheable);
4. Interface Uniforme: o REST definido por quatro limitaes de
interface: identificao de recursos, manipulao de recursos
atravs de representaes; mensagens auto-descritivas e a
hipermdia como motor de estado de aplicao;
5. Sistema em Camadas: ao restringir o conhecimento do sistema a
uma nica camada, colocado um limite na complexidade geral do
sistema, promovendo a independncia entre eles;
6. Cdigo Sob Demanda: o REST permite que a funcionalidade de
um cliente seja estendida atravs do download e execuo de
cdigos na forma de scripts ou applets.


49



Neste sentido, pode-se definir o REST como um princpio arquitetural e
um mtodo de construo de sistemas distribudos que utiliza os conceitos da
Web como os hipertextos e seu principal protocolo de transferncia, o
Hypertext Transfer Protocol (HTTP) (Fielding R. T., 2000). O conceito central
do REST est em tratar tudo como um recurso, sendo este recurso uma fonte
para uma informao especfica. Os recursos so identificados atravs de um
Universal Resource Identifier (URI) (Mealling & Denenberg, 2002), onde um
esquema define a forma como a informao deve ser acessada, seguida de
informaes de acesso, se necessrio e o servidor e porta em cujo recurso
est localizado. A sintaxe de uma URI mostrada na listagem 4.1 e dois
exemplos de utilizao so mostrados na listagem 4.2.



<esquema>://[login[:senha]@]<host>[:porta][/recurso]

Listagem 4.1. Sintaxe de um Universal Resource Identifier (URI). O host tambm
identificado como namespace. Fonte: (Mealling & Denenberg, 2002).


Exemplo A
http://www.google.com/mail

Esquema: http
Host: www.google.com
Recurso: /mail

Exemplo B
ftp://eloy:123321@ftp.servidor.com.br/dir/subdir

Esquema: ftp
Login: eloy
Senha: 123321
Host: ftp.servidor.com.br
Recurso: /dir/subdir
Listagem 4.2. Exemplos de Universal Resource Identifier (URI). Fonte: (Mealling &
Denenberg, 2002).


4.2.1 Principais Caractersticas

Na seo anterior foi apresentado o conceito de REST, recursos e
URIs. Esta seo apresenta os princpios centrais governam a arquitetura.


50


Tilkov (Tilkov, 2007) destacou as seguintes caractersticas, que fazem com que
o REST seja aplicvel em qualquer sistema:

Atribua uma identificao a todas unidades do seus recursos;
Ligue os recursos entre si;
Utilize os mtodos padronizados;
Apresente recursos com mltiplas representaes;
Comunique sem controle de estado.

As prximas sees tratam em detalhe das caractersticas
supracitadas.

4.2.1.1 Atribuio de Identificao

O conceito de um recurso de identificao universal, como uma URI,
permite que as principais abstraes existentes em um sistema sejam
identificadas em um ponto central. Este ponto central tambm identificado
como recurso. A identificao deve ser uma forma de atribuir um valor nico e
global para identificar um recurso especfico dentro do seu namespace
(listagem 4.1) (Mealling & Denenberg, 2002).

O REST j fornece uma diretriz de identificao global, sendo o seu
principal benefcio ser um padro j conhecido e que funciona bem numa
escala global. A listagem 4.3 apresenta exemplos de como estes recursos
podem contar com identificadores globais. Quando confrontados com a idia de
atributos de identificao globais, arquitetos podem confundir estes
identificadores como sendo diretamente as chaves primrias de uma tupla no
banco de dados. Porm, estes entidades podem ser ainda mais abstratas que
uma entrada no banco de dados: um pedido (como na listagem 4.3, b) pode ser
composto de diversos itens, endereos e muitos outros aspectos que podem
no ser relevantes ao ponto de serem expostos individualmente, sim de uma
forma agrupada (Tilkov, 2007).



51


a) http://exemplo.com/clientes/1234
b) http://exemplo.com/pedidos/2009/05/99834
c) http://exemplo.com/produtos/449
d) http://exemplo.com/processos/aumento-salario-234
Listagem 4.3. Exemplo de atributos com identificadores globais, utilizando a estrutura de
uma URI. Fonte: (Tilkov, 2007).

Alm de identificadores nicos para um registro, o REST oferece um
padro tambm para identificao de colees de itens. A listagem 4.4
apresenta dois exemplos: o primeiro pode obter todos os pedidos no ms de
maio do ano de 2009, j no segundo exemplo, pode-se obter todos os produtos
da cor verde.

a) http://exemplo.com/pedidos/2009/05
b) http://exemplo.com/produtos?cor=verde
Listagem 4.4. Exemplo de obteno de colees atravs de identificadores nicos. Fonte:
(Tilkov, 2007).

O uso de URIs juntamente com identificadores de uma entidade so o
princpio bsico da localizao de recursos dentro da arquitetura REST. Este
princpio se aplica tanto para um nico registro como para uma coleo deles.

4.2.1.2 Ligao Entre Recursos

Fielding (Fielding R. T., 2000) descreve o conceito de hipermdia como
motor para o estado da aplicao (hypermidia as the engine of application
state ou somente HATEOAS), que consiste na idia de que links so as
principais formas de referenciar informaes, onde o servidor fornece links para
recursos e o cliente responsvel por tomar este link e levar o estado da
aplicao para o prximo, por seguir o link referenciado.

A listagem 4.5 mostra um exemplo de um fragmento XML que utiliza o
conceito de ligao entre recursos. fcil identificar qual o produto que
compe o pedido, basta consumir o link para o recurso que est apontado no


52


atributo ref da tag produto. A grande vantagem de utilizar este padro que
recursos de outras aplicaes podem ser referenciados facilmente. O padro
utilizado pelo REST permite ainda que mudando somente a referncia ao
namespace, possvel utilizar aplicao de outros fabricantes em um nvel
global.

<pedido id=http://exemplo.com/pedidos/2009/05//99834>
<quantidade>34</quantidade>
<produto ref=http://exemplo.com/produtos/449 />
<cliente ref=http://exemplo.com/clientes/1234 />
</pedido>
Listagem 4.5. A ligao entre recursos permite que o cliente possa mudar o estado da
aplicao atravs do consumo de um link. Fonte: (Tilkov, 2007).

4.2.1.3 Mtodos Padronizados

O REST utiliza um subconjunto de mtodos disponveis no protocolo
HTTP para realizar suas operaes. De acordo com a especificao do
protocolo HTTP em (Fielding, et al., 2004) e a arquitetura definida por Fielding
(Fielding R. T., 2000), os mtodos utilizados pelo REST so:

1. GET: uma operao de somente leitura. Esta operao
idempotente e segura, significando que no importa a quantidade
de vezes que a operao seja aplicada, ou seja, o recurso seja lido,
o resultado deve ser sempre o mesmo. O ato de ler um documento
HTML no deve mudar o documento. Segura significa que ao
invocar uma operao GET o estado do servidor no ir ser
alterado, ou seja, alm da do consumo de recursos de CPU e
memria do servidor, nada mais ser afetado (Burke, 2008);
2. PUT: geralmente relacionada com uma operao de insero ou
atualizao. Assim como o GET, tambm idempotente, porm ao
usar o PUT, o cliente deve ter em mos o recurso que est se
criando ou atualizando. A operao idempotente pois ao enviar
mais de uma requisio no ir afetar o servio em questo. Burke


53


(Burke, 2008) faz uma analogia com o processador de textos
Microsoft Word: no importa a quantidade de vezes que voc clica
no boto Salvar, o arquivo que ser armazenado ser logicamente
o mesmo documento;
3. DELETE: utilizado para remover servios. idempotente, ao passo
que remover algo que j no est l no um problema;
4. POST: a nica operao no idempotente e insegura do HTTP.
Este mtodo no sofre muitas limitaes exatamente para prover
ao sistema a possibilidade de executar outras operaes fora do
contexto do GET (leitura), PUT (insero e atualizao) e DELETE
(remoo). No REST, utilizada para modelar um servio de
fabricao de objetos. Quando se usa o mtodo PUT, sabe-se
exatamente o que est sendo criado, com o POST, atribudo ao
servidor a tarefa de criar o objeto.

A adoo de uma arquitetura que utilize os mtodos HTTP de acordo
com os princpios do REST uniformemente para toda uma aplicao garante
que ela ser parte integrante da Web. Desta forma, browsers e outras
aplicaes que implementam o protocolo HTTP podero comunicar-se com a
aplicao, onde o nico ponto de acoplamento ser o namespace e os
recursos a serem acessados (Tilkov, 2007).

Tilkov exemplificou a aplicao dos mtodos atravs de um sistema de
compras, onde um cliente possui diversos pedidos e um pedido possui um ou
mais itens. Atravs da exposio dos servios deste sistema, como mostrado
na figura 4.6, possvel derivar quais operaes sero realizadas pelos quatro
mtodos utilizados pelo REST.

A tabela 4.7 apresenta o mapeamento dos servios RESTful, ou seja,
aderentes arquitetura REST. Tilkov argumenta que possvel mapear
qualquer mtodo utilizando os princpios da arquitetura REST, exemplificando
que o resultado da chamada do mtodo obterDetalhesCliente o mesmo
que uma requisio ao recurso /clientes/{id} com o mtodo GET.



54









Figura 4.6. Diagrama de Classes representando a exposio de servios de um sistema
de compras, compreendido por um cliente, pedidos e itens de um pedido. Fonte: (Tilkov,
2007).

GET PUT POST DELETE
/pedidos
Listar todos
os pedidos
No
utilizado
Adicionar
novo
pedido
No utilizado
/pedidos/{id}
Obter
detalhes do
pedido
Atualizar
pedido
Adicionar
item
Cancelar
pedido
/clientes
Listar todos
os clientes
No
utilizado
Adicionar
novo
cliente
No utilizado
/clientes/{id}
Obter
detalhes do
cliente
Atualizar
cliente
No
utilizado
Remover
Cliente
/clientes/{id}/pedidos
Obter
todos os
pedidos
para cliente
No
utilizado

Adicionar
pedido
Cancelar
todos os
pedidos do
cliente
Tabela 4.7. Mapeamento entre recursos e os mtodos do protocolo HTTP, indicando
quais funes so realizadas de acordo com cada mtodo. Fonte: (Tilkov, 2007).

Em resumo, para os clientes estarem aptos a interagir com os recursos
de um servidor, estes servios devem implementar o protocolo de aplicao
padro (neste caso, o HTTP) corretamente, atravs do uso padronizado dos
mtodos GET, PUT, POST e DELETE.

4.2.1.4 Recursos com Mltiplas Representaes

Um cliente que implementa as especificaes do protocolo HTTP pode
realizar uma consulta a um servio qualquer. Isso implica que o cliente deve
+ obterPedidos()
+ enviarPedidos()
+ obterDetalhesPedido()
+ obterPedidosParaCliente()
+ atualizarPedido()
+ adicionarItemPedido()
+ cancelarPedido()
ServicoGerenciamentoPedido
+ obterClientes()
+ adicionarCliente()
+ obterDetalhesCliente()
+ atualizarCliente()
+ removerCliente()
ServicoGerenciamentoCliente


55


conhecer o formato no qual os dados sero retornados, a fim de realizar
operaes sobre estes dados (Burke, 2008).

O protocolo HTTP permite que o cliente ou o servidor informem o tipo
de representao que est sendo utilizado na requisio ou resposta,
permitindo que ambas as partes realizem a interpretao correta dos dados a
serem processados (Fielding, et al., 2004). A listagem 4.8 mostra um exemplo
de uma requisio HTTP onde um cliente pode informar quais formatos est
preparado para interpretar, como o XML ou o JavaScript Object Notation
(JSON).

GET /pedidos/1234
Host: exemplo.com
Accept: text/json, text/xml
Listagem 4.8. Exemplo de requisio HTTP onde o cliente informa quais tipos de dados
est apto a receber. O campo de cabealho Accept indica os tipos de mdia que so
aceitveis para resposta, com a precedncia da direita para esquerda. Fonte: (Fielding, et
al., 2004).

Um servio REST deve prover diversas formas de representar um
dado, a fim de garantir que diversos tipos de clientes possam realizar
processamentos sobre estes dados (Fielding R. T., 2000).

4.2.1.5 Comunicao Sem Controle de Estado

Para o REST, uma comunicao sem estado (stateless) define que no
deve haver dados da sesso do cliente armazenados no servidor, mas isso no
significa que a aplicao que expe seus servios de uma forma RESTful no
possa manter estados internos (Burke, 2008). Se h necessidade de manter
dados especficos sobre a sesso, o cliente responsvel por mant-los, e
transferi-los para o servidor sempre que necessitar realizar uma operao.
Burke diz que para uma camada de servio que no tem que manter sesses
de clientes muito mais fcil embutir escalabilidade, pois as replicaes em um
sistema distribudo utilizando clusters se torna menos custosa.



56


4.3 Interface de Consultas

Na seo anterior foi apresentado o REST, uma arquitetura composta
de princpios de desenvolvimento de sistemas distribudos que conta com o
protocolo HTTP como transporte e a Web como conceito central para
estruturao de informaes a serem trafegadas. O REST prov quatro
mtodos que podem ser mapeados a qualquer entidade de negcio ou de
forma mais abstrata, so eles: GET, PUT, POST e DELETE (Fielding R. T.,
2000). Com o emprego destes quatro mtodos e a padronizao da
nomenclatura de acesso a recursos atravs de uma URI, possvel usufruir da
ubiqidade da Web e eliminar o custo por parte do servidor no armazenamento
de estados de sesso e sincronizao de cache em um cluster durante
operaes de requisio e resposta, pelo fato do HTTP ser um protocolo sem
estado (Tilkov, 2007).

O CouchDB utiliza o REST como interface padro de consulta,
insero, atualizao e remoo de dados. possvel acessar as views
disponibilizados pelo CouchDB, como mostradas no captulo 3, e partir delas
extrair informaes do banco de dados utilizando um simples cliente HTTP,
como um browser. O formato padro de estruturao de dados o JSON,
apresentado no captulo 2. Por ser uma notao padro para linguagem
JavaScript, que implementada em browsers como Firefox, Internet Explorer,
Safari e Opera (Wikipedia, 2009), torna-se simples obter e manipular dados
partir de um banco de dados CouchDB dentro de um ambiente Web moderno,
como so os browsers (Anderson, et al., 2009).

Esta seo ir mostrar como realizar operaes remotas no CouchDB,
utilizando o exemplo de um blog, detalhado no captulo 3, porm, com uma
pequena alterao: os documentos apresentados na listagem 3.4 receberam
um novo campo chamado _id, que consiste num identificador nico para um
documento dentro de um banco de dados utilizado pelo CouchDB (Anderson,
et al., 2009).



57


4.3.1 Seleo

Os princpios arquiteturais do REST estabelecem que para qualquer
recurso, deve ser necessrio atribuir um identificador nico, que consiste numa
forma de obter dados a partir do servidor para o recurso que ser consultado.
(Fielding R. T., 2000). No CouchDB, o recurso o nome do banco de dados,
sob o qual estaro armazenados diversos documentos. Cada documento deve
possuir um identificador, que pode ser atribudo automaticamente pelo
CouchDB ou pelo usurio que est criando o documento (Anderson, et al.,
2009).

A listagem 4.9 mostra como ser utilizada a API REST do CouchDB
para obteno do registro com identificao 1. Para isso, uma consulta
realizada utilizando o protocolo HTTP. O CouchDB possui uma implementao
do servidor HTTP, compatvel com a arquitetura REST (Apache CouchDB,
2009). A listagem 4.9 exemplifica como realizada uma consulta utilizando o
comando HTTP GET atravs de uma conexo via telnet. O resultado da
consulta mostrado na figura 4.10.


GET /blog/1

Listagem 4.9. Requisio de seleo em uma base de dados CouchDB utilizando o
protocolo HTTP.

4.3.2 Insero

A insero de documentos em um banco de dados CouchDB utiliza o
mtodo PUT do protocolo HTTP, onde o usurio deve informar qual ser a
identificao do documento. Caso seja necessrio criar uma identificao
automtica, o CouchDB realiza esta tarefa atravs da criao de documentos
pelo mtodo POST, onde ao invs de informar o identificador (como
exemplificado na listagem 4.11), o usurio informa somente o nome do banco
de dados. (Apache CouchDB, 2009).
recurso
identificador


58





Figura 4.10. Resultado da consulta realizada com o mtodo GET a uma base de
documentos CouchDB.

Na listagem 4.11 mostrado o cabealho HTTP juntamente com seu
corpo, que composto do documento no formato JSON. Como visto no
captulo 2, o JSON permite a criao de objetos e arrays de forma simplificada,
portanto, para atribuir um novo parmetro ao documento, basta declar-lo na
estrutura do corpo da mensagem de requisio HTTP, como exemplificado com
o campo categoria, que classifica a categoria do post realizado no blog
(Anderson, et al, 2009).

A figura 4.12 mostra o resultado desta consulta diretamente com o
servidor HTTP do CouchDB. Pode-se perceber que a reposta do servidor
indicou que o documento foi adicionado com sucesso (ok: true),
indicando a identificado utilizada (id: 3) e tambm o cdigo da reviso
armazenada no banco (rev: 3545821650).





59



PUT /blog/3
Content-Length: 141
Content-Type: application/json

{"titulo": "Terceiro Post","autor": "Leonardo
Eloy","corpo": "Um terceiro post no blog","data":
"21/06/2009 12:30:21", "categoria": "testes"}

Listagem 4.11. Requisio de insero de documento em uma base CouchDB utilizando
o mtodo PUT, exemplificando a incluso de um novo campo.




Figura 4.12. Resultado de uma insero realizada atravs do mtodo PUT do HTTP para o
CouchDB.

4.3.3 Atualizao

Assim como a insero, a atualizao de documentos pode ser feita
por intermdio dos mtodos PUT ou POST, porm, necessrio informar a
identificao do documento no cabealho da requisio no caso do PUT ou no
Identificador atribudo
novo campo
corpo da requisio
cabealho


60


corpo da requisio atravs do campo _id, no caso do POST. Alm da
identificao, necessrio informar o valor da reviso que ser atualizada,
podendo assim o banco realizar o gerenciamento de conflito de verses como
mostrado no captulo 2 (Apache CouchDB, 2009).

A listagem 4.13 mostra a atualizao do documento 3 e reviso
449998918. Nesta atualizao, foi expandido o campo categoria adicionado na
seo anterior, agora informado um array de categorias, possibilitando
mltiplas classificaes de um post no blog. Na prtica, este consulta pode ser
realizada por um cliente HTTP.


PUT /blog/3
Content-Length: 183
Content-Type: application/json

{"_id":"3","_rev":"449998918","autor": "Leonardo
Eloy","titulo": "Terceiro Post","data": "21/06/2009
12:30:21","corpo": "Um terceiro post no blog","categoria":
["testes", "CouchDB!"]}

Listagem 4.13. Envio de uma requisio PUT para atualizar o documento. A identificao
e a ltima reviso devem ser informadas para garantir a atualizao sem conflitos.

novas categorias


61



Figura 4.14. Requisio de atualizao no CouchDB, o banco retornou o identificador da
nova reviso que est em vigor.


Como mostrado no captulo 2, o CouchDB criou uma nova reviso do
documento aps a sua atualizao. As figuras 4.15 e 4.16 mostram a tela do
sistema de gerenciamento do CouchDB, chamado Futon, apresentado no
captulo 2, onde se pode navegar pelas duas revises armazenadas no banco.



Figura 4.15. Primeira reviso cadastrada no banco de dados do documento sendo
trabalhado.



62



Figura 4.16. Segunda reviso do documento, aps a atualizao descrita na listagem
4.13.

4.3.4 Remoo

A remoo de um documento realizada atravs de uma requisio
com o mtodo DELETE. A identificao do documento deve ser passada como
parmetro na URI e a reviso pode ser tambm inserida na URI como um
parmetro ou ento enviada no cabealho da requisio, com a tag If-Match
(Apache CouchDB, 2009). A listagem 4.17 mostra um exemplo de uma
remoo utilizando a reviso agregada com a URI e a listagem 4.18 exibe
como se d a remoo com o nmero da reviso sendo passado atravs do
cabealho. A figura 4.19 mostra o resultado da execuo da primeira requisio
realizada ao CouchDB.


DELETE /blog/3?rev=3267045847

Listagem 4.17. Exemplo de um requisio de remoo de documento, informando o
nmero da reviso como parmetro juntamente com a URI.





63



DELETE /blog/3
If-Match: 3267045847

Listagem 4.18. Requisio que realiza a remoo da reviso declarada no cabealho If-
Match.


Figura 4.19. Resultado de uma requisio remoo de um documento junto ao servidor
do CouchDB.

4.3.5 Utilizando Views

Importantes ferramentas para consulta aos dados armazenados, as
views como utilizadas no CouchDB, apresentadas no captulo 3, so
compostas de uma funo de mapeamento, que tem como objetivo obter um
conjunto de dados intermedirio e uma segunda funo de reduo, que ir
realizar a filtragem e agrupamento das informaes intermedirias obtidas
(Anderson, et al., 2009). Assim como o CouchDB prov uma API REST para
consulta ao banco de dados, tambm disponibilizada uma API para
manipulao especificamente de views, possibilitando a criao, alterao e
remoo destes objetos atravs de uma consulta HTTP (Apache CouchDB,
2009).


64



O CouchDB disponibiliza uma aplicao Web para gerenciamento de
suas instncias chamada Futon, como apresentado no captulo 2. Esta
aplicao implementa diretamente as APIs REST disponibilizadas pelo
servidor, onde o browser, que tambm implementa o protocolo HTTP, serve
como cliente para realizar chamadas remotas s APIs (Lennon, 2009).

A figura 4.20 mostra a criao da view descrita na seo 3.3.1.2, cujo
objetivo obter a listagem de posts por autor. No ambiente do Futon,
possvel projetar as funes de mapeamento e reduo, observando se o
resultado de sua execuo satisfatrio e ento armazenar a view de forma
permanente no CouchDB. necessrio informar um nome de projeto, que ser
um agrupador, alm do prprio nome da view (Lennon, 2009).

Assim como em uma consulta, as views podem ser acessadas atravs
do mtodo GET, onde a URI a ser referenciada dever conter o nome do banco
de dados, um recurso com valor fixo que indica que ser realizada uma
consulta a uma view, seguido do nome do projeto (agrupador), finalizando com
o nome da view, tornando a composio da URI de fcil leitura e identificao
(Lennon, 2009). A figura 4.21 mostra uma consulta realizada no CouchDB
utilizando a view construda na figura 4.20.





65



Figura 4.20. Criao de uma view no CouchDB, utilizando o Futon, uma interface de
administrao do banco de dados. Os itens (a) e (b) apontam a funo de mapeamento e
reduo, cujo objetivo listar todos os posts realizados por um autor. Ao clicar no boto
apontado pelo item (c), o usurio obtm o resultado da consulta, como mostrado no item
(e). Aps finalizada a criao da consulta, o usurio pode salvar a view, disponibilizando
a sua utilizao atravs de uma API especfica.


Figura 4.21. Execuo de uma consulta a uma view.


4.4 Consideraes Finais

(e) resultado da execuo
(f) salvar a
definio da view
(a) funo de mapeamento (b) funo de reduo
(c) executar consulta


66


Neste captulo foi apresentado o Representational State Transfer
(REST), que consiste em um conjunto de princpios arquiteturais voltados para
o desenvolvimento de sistemas distribudos utilizando o Hypertext Transfer
Protocol (HTTP) como protocolo de transporte e a Web como contexto
arquitetural. Para um sistema ser compatvel com a arquitetura REST, dever
utilizar os seguintes princpios (Fielding R. T., 2000):

Atribuir um identificador nico a todos os recursos;
Referenciar um recurso atravs de um link;
Utilizar os mtodos padronizados do protocolo HTTP (GET, PUT,
POST e DELETE);
Apresentar recursos com mltiplas representaes estruturais
(JSON, XML, HTML, entre outros);
Manter o estado da sesso no cliente, sempre enviando o estado
ao servidor, ao passo que o HTTP um protocolo sem estado (stateless).

O REST utiliza o padro de Universal Resource Identifier (URI), que
uma especificao projetada para possibilitar um padro unificado de
identificao de recursos. Atravs de uma URI e dos quatro mtodos HTTP
supracitados, a arquitetura REST permite a realizao de virtualmente qualquer
nmero de operaes em entidades representadas por recursos, como
exemplificado na tabela 4.7 (Tilkov, 2007).

Por representar um padro arquitetural regido por princpios de
desenvolvimento distribudo em cima de um protocolo de aplicao maduro e
com suporte a diversos tipos de mdias, o REST apresenta todas as
ferramentas necessrias servir de interface entre o usurio e um banco de
dados orientado a documentos, haja vista que um dos princpios fundamentais
destes tipos de sistemas de banco de dados a forte integrao com a Web
(Anderson, et al., 2009).

Visando exemplificar como o REST pode ser utilizado como interface
de consultas para um banco de dados orientado a documentos, foi apresentado
como este princpio arquitetural utilizando com o CouchDB. Apresentou-se as


67


quatro operaes bsicas de criao, insero, atualizao e remoo de
documentos, alm de como possvel consultar as views, estruturas que
utilizam o framework MapReduce para consulta de dos no CouchDB (Apache
CouchDB, 2008), como apresentado no captulo 3.



68







Captulo 5 Concluso e Trabalhos Futuros

Neste trabalho foi apresentado o Estado da Arte em Bancos de Dados
Orientados a Documentos (BDOD), onde identificou-se que documentos so
amplamente utilizados em organizaes, mas a sua utilizao como modelo de
estrutura e armazenamento de dados s tornou-se popular com o crescimento
cada vez maior da Web e os decrescentes custos de peas de hardware. Desta
forma, a necessidade de criao de um novo paradigma de modelagem,
armazenamento, consulta e apresentao de dados para refletir a estrutura de
um documento do mundo real tornou-se mais evidente.

O paradigma proposto implementado pelo CouchDB, um banco de
dados orientado a documentos distribudo, livre de esquema e acessvel
atravs da uma API RESTful. O CouchDB uma implementao de referncia
com avanados conceitos no que concerne ao estado da arte deste novo
paradigma de modelagem e armazenamento de dados. Os principais
componentes e conceitos do CouchDB so:

Utilizao da Web como interface padro de consultas;
Armazenamento e apresentao de dados utilizando o padro
JavaScript Object Notation (JSON);
Replicao de dados multi-master e bi-direcional utilizando as
caractersticas distribudas do Erlang, linguagem na qual foi
implementado.



69


Um comparativo entre os Bancos de Dados Relacionais e sua
contrapartida Orientada a Documentos foi apresentado, onde as principais
diferenas esto na modelagem dos dados, onde nos SGBDRs necessria a
diviso das informaes em diversas tabelas, ligando-as atravs do conceito de
chaves estrangeiras. Nos BDODs utilizado o conceito de dados autocontidos,
onde a definio do qu compe o documento j est declarado como um todo,
sem referncias a dados externos. Diferenas salutares tambm so
encontradas no compartilhamento global, onde nos BDODs o conceito de
arquitetura sem compartilhamento (shared-nothing architecture) utilizado,
alm de diferenas durante o processamento de uma transao, onde os
BDODs no utilizam bloqueios e outras propriedades arquiteturais, como
armazenamento (cacheing) nativo em nvel de protocolo (HTTP).

O conceito de views para agregao e filtragem de dados e a utilizao
do MapReduce como framework para distribuio das consultas a views para
diversos ns distribudos como pequenas unidades de trabalho, permite que os
BDODs operem em um ambiente distribudo mantendo alta eficincia no
processamento de dados.

O Hypertext Transfer Protocol (HTTP) utilizado como protocolo de
transporte para realizao de consultas, operaes de atualizao e remoo
de dados e administrao do banco de dados. Por ser um protocolo sem
estado (stateless) e com recursos de armazenamento (cacheing), a
escalabilidade do protocolo HTTP utilizada como uma importante propriedade
dos BDODs. O modelo arquitetural Representational State Transfer (REST)
permite a padronizao do acesso a recursos de banco, garantindo uma
interface uniforme de consulta e manipulao de dados.

So vistas claras oportunidades de trabalhos futuros com o estudo de
viabilidade da utilizao do paradigma orientado a documentos como
consistncia eventual, replicao e consultas com MapReduce em dispositivos
mveis, onde a sua utilizao no cotidiano assume papis similares aos
desempenhados por documentos. Tambm so vistas oportunidades em


70


identificar a melhor forma de projetar sistemas orientados a documentos e
identificar padres de desenvolvimento de aplicaes que utilizam BDODs.















71


BIBLIOGRAFIA
Anderson, J. C., Lehnardt, J., & Slater, N. (2009). CouchDB: The Definitive
Guide, 1st Edition. Sebastopol, California: O'Reilly Media, Inc.
Apache CouchDB. (17 de Maio de 2009). HTTP Documento API. Acesso em 19
de Maio de 2009, disponvel em CouchDB Wiki:
http://wiki.apache.org/couchdb/HTTP_Document_API
Apache CouchDB. (01 de Maio de 2008). Introduction. Acesso em 20 de Maio
de 2009, disponvel em Apache CouchDB:
http://couchdb.apache.org/docs/intro.html
Apache CouchDB. (01 de Maio de 2008). Technical Overview. Acesso em 20
de Maio de 2009, disponvel em Apache CouchDB:
http://couchdb.apache.org/docs/overview.html
Apache Group. (01 de Janeiro de 2004). Apache License, Version 2.0. Acesso
em 20 de Maio de 2009, disponvel em Apache Group:
http://www.apache.org/licenses/LICENSE-2.0
Apache Group. (12 de Abril de 2009). Introduction to CouchDB views. Acesso
em 21 de Abril de 2009, disponvel em CouchDB Wiki:
http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views
Apache Hadoop. (14 de Fevereiro de 2007). Project Description. Acesso em 14
de Abril de 2009, disponvel em Hadoop:
http://wiki.apache.org/hadoop/ProjectDescription
Arvin, T. (04 de Maro de 2009). Comparision of different SQL implementations.
Acesso em 30 de Maio de 2009, disponvel em Troels Arvin's home
page: http://troels.arvin.dk/db/rdbms/
Berners-Lee, T. (2001). Weaving the Web. New York: Texere Publishing.
Burke, B. (18 de Agosto de 2008). Introduction to REST. Acesso em 17 de Maio
de 2009, disponvel em Developer Zone:
http://architects.dzone.com/articles/intro-rest
Chu-Carrol, M. (22 de Janeiro de 2008). Databases are hammers; MapReduce
is a screwdriver. Acesso em 14 de Abril de 2009, disponvel em Good
Math:
http://scienceblogs.com/goodmath/2008/01/databases_are_hammers_m
apreduc.php


72


Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks.
Communications of the ACM , 13 (6), pp. 377-387.
Colouris, G., Dollimore, J., & Kindberg, T. (2007). Sistemas Distribudos:
Conceitos e Projeto, 4a. edio. Porto Alegre: Bookman Companhia
Editora.
Dean, J., & Ghemawat, S. (Dezembro de 2004). Acesso em 15 de Abril de
2009, disponvel em http://labs.google.com/papers/mapreduce-osdi04-
slides/index-auto-0007.html
Dean, J., & Ghemawat, S. (Dezembro de 2004). MapReduce: Simplified Data
Processing on Large Clusters. OSDI'04: Sixth Symposium on Operating
System Design and Implementation .
DeWitt, D. J., & Stonebraker, M. (17 de Janeiro de 2008). MapReduce: A major
step backwards. Acesso em 14 de Abril de 2009, disponvel em
Database Column:
http://www.databasecolumn.com/2008/01/mapreduce-a-major-step-
back.html
Domnio Contabilidade. (23 de Janeiro de 2008). Modelos de Notas Fiscais.
Acesso em 30 de Maio de 2009, disponvel em Domnio contabilidade:
http://dominiocontabilidade.com.br/modelonotas/modeloservicos.htm
Duskis, S. (14 de Maio de 2009). REST - Presented in HTTP. Acesso em 17 de
Maio de 2009, disponvel em Developer Zone:
http://architects.dzone.com/news/solomon-duskis-rest-presented
ECMA. (01 de Dezembro de 1999). ECMAScript Language Specification. (3rd).
Genebra, Sua.
Elmasri, R., & Navathe, S. B. (2005). Sistemas de Banco de Dados, 4a edio.
So Paulo: Pearson Education do Brasil.
Erlang. (28 de Abril de 2009). Open-source Erlang - White Paper. Acesso em
30 de Maio de 2009, disponvel em Erlang:
http://erlang.org/white_paper.html
Fielding, R. T. (2000). Architectural Styles and the Design of Network-based
Software Architectures. University of California Irvine .
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., et al. (01
de Setembro de 2004). Hypertext Transfer Protocol -- HTTP/1.1. (T. I.
Society, Produtor) Acesso em 17 de Maio de 2009, disponvel em RFC
2616: http://www.w3.org/Protocols/rfc2616/rfc2616.html


73


Greengard, S. (2009). Learning goes global. Communications of the ACM , 52
(5).
Guo, J., Hu, Z., Chan, C.-K., Luo, Y., & Chan, C. (2008). Document-Oriented
Heterogeneous Business Process Integration throught Collaborative E-
Marketplace. 10th Int. Conf. on Electronic Commerce (ICEC) 08.
Innsbruck: ACM.
Hrder, T., & Rothermel, K. (1987). Concepts for transaction recovery in nested
transactions. ACM SIGMOD (pp. 239-248). New York: ACM.
Ho, R. (19 de Outubro de 2008). CouchDB Implementation. Acesso em 30 de
Maio de 2009, disponvel em Pragmatic Programming Techniques:
http://horicky.blogspot.com/2008/10/couchdb-implementation.html
International Organization for Standardization. (2008). Information technology --
Database languages -- SQL -- Part 1: Framework (SQL/Framework).
Genebra, Suica: ISO.
Jorgensen, G. (17 de Dezembro de 2008). Relational Database Experts Jump
The MapReduce Shark. Acesso em 14 de Abril de 2009, disponvel em
Typical Programmer:
http://typicalprogrammer.com/programming/mapreduce/
JSON. (01 de Janeiro de 2008). Introducing JSON. Acesso em 30 de Maio de
2009, disponvel em JSON: http://www.json.org/
Katz, D. (07 de Abril de 2008). Compaction. Acesso em 24 de Maio de 2009,
disponvel em Damian Katz:
http://damienkatz.net/2008/04/compaction.html
Kowarski, I., & Lopez, M. (1982). The Document Concept in a Data Base.
France: ACM.
Lennon, J. (31 de Maro de 2009). Exploring CouchDB: A document-oriented
database for Web applications. Acesso em 19 de Maio de 2009,
disponvel em IBM developerWorks:
http://www.ibm.com/developerworks/opensource/library/os-
couchdb/index.html
Mealling, M., & Denenberg, R. (Agosto de 2002). Uniform Resource Identifiers
(URIs), URLs, and Uniform Resource Names (URNs): Clarifications and
Recommendations. RFC 3305 .
Moore, K. (1995). The Lotus Notes(tm) Storage System. San Jose: ACM
SIGMOD.


74


Murphy, S. (08 de Setembro de 2008). CouchDB View Generation. Acesso em
21 de Abril de 2009, disponvel em Hello, I Am Sean Murphy:
http://iamseanmurphy.com/2008/09/08/couchdb-view-generation/
Sarma, S. (4 de Junho de 2008). Engineering @ Facebook's Notes. Acesso em
14 de Abril de 2008, disponvel em Facebook:
http://www.facebook.com/note.php?note_id=16121578919
Sierra, J. L., Fernndez-Valmayor, A., Fernndez-Manjn, B., & Navarro, A.
(2004). ADDS: A Document-Oriented Approach for Application
Development. Journal of Universal Computer Science , pp. 1302-1324.
Silberschatz, A., Korth, H. F., & Sudarshan, S. (2006). Sistema de Banco de
Dados. Rio de Janeiro: Elsevier.
Tilkov, S. (10 de Dezembro de 2007). A Brief Introduction to REST. Acesso em
17 de Maio de 2009, disponvel em InfoQ:
http://www.infoq.com/articles/rest-introduction
Wikipedia. (17 de Maio de 2009). Comparison of web browsers - JavaScript
support. Acesso em 18 de Maio de 2009, disponvel em Wikipedia:
http://en.wikipedia.org/wiki/Comparison_of_web_browsers#JavaScript_s
upport