Você está na página 1de 144

WBA0751_v1.

BANCOS DE DADOS NÃO


RELACIONAIS (NOSQL)
Marcelo de Lima Tavares
Marcio dos Santos
Sergio Eduardo Nunes

Bancos de dados não relacionais (NoSQL)

1ª edição

Londrina
Editora e Distribuidora Educacional S.A.
2019

2
© 2019 por Editora e Distribuidora Educacional S.A.
Todos os direitos reservados. Nenhuma parte desta publicação poderá ser
reproduzida ou transmitida de qualquer modo ou por qualquer outro meio,
eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo de
sistema de armazenamento e transmissão de informação, sem prévia autorização,
por escrito, da Editora e Distribuidora Educacional S.A.

Presidente
Rodrigo Galindo

Vice-Presidente de Pós-Graduação e Educação Continuada


Paulo de Tarso Pires de Moraes

Conselho Acadêmico
Carlos Roberto Pagani Junior
Camila Braga de Oliveira Higa
Carolina Yaly
Giani Vendramel de Oliveira
Juliana Caramigo Gennarini
Nirse Ruscheinsky Breternitz
Priscila Pereira Silva
Tayra Carolina Nascimento Aleixo

Coordenador
Nirse Ruscheinsky Breternitz

Revisor
Cecilia Sosa Arias Peixoto

Editorial
Alessandra Cristina Fahl
Beatriz Meloni Montefusco
Daniella Fernandes Haruze Manta
Hâmila Samai Franco dos Santos
Mariana de Campos Barroso
Paola Andressa Machado Leal

Dados Internacionais de Catalogação na Publicação (CIP)


__________________________________________________________________________________________
Nunes, Sergio Eduardo
N972b Bancos de dados não relacionais (NoSQL)/ Sergio
Eduardo Nunes, Marcelo de Lima, Marcio dos Santos
Tavares – Londrina: Editora e Distribuidora Educacional S.A. 2019.
141 p.

ISBN 978-85-522-1603-2

1. Segurança em banco de dados. 2. Integridade de


dados. I. Nunes, Sergio Eduardo. II. Tavares, Marcelo de
Lima. III. Santos, Marcio.Título.

CDD 004
____________________________________________________________________________________________
Thamiris Mantovani CRB: 8/9491

2019
Editora e Distribuidora Educacional S.A.
Avenida Paris, 675 – Parque Residencial João Piza
CEP: 86041-100 — Londrina — PR
e-mail: editora.educacional@kroton.com.br
Homepage: http://www.kroton.com.br/

3
BANCOS DE DADOS NÃO RELACIONAIS (NoSQL)

SUMÁRIO
Apresentação da disciplina__________________________________________________ 05

Bancos de dados não convencionais: introdução aos principais modelos de


dados NoSQL _______________________________________________________________ 06

Modelo de sintaxe XML e JSON _____________________________________________ 28

Estrutura do MongoDB e Hadoop e seus usos práticos _____________________52

Banco de dados NoSQL: modelo orientado a documentos__________________73

Modelo orientado a chave/valor ________________________________________ 93

Modelo orientado a família de colunas______________________________________ 108

Modelo orientado a grafos __________________________________________________ 123

4
Apresentação da disciplina

Olá aluno! Seja muito bem-vindo ao mundo dos dados!

Esta disciplina apresentará a você os principais conceitos e definições


de bancos de dados não relacionais, conhecidos como NoSQL, realizará
comparativos paralelos com os bancos de dados relacionais, conhecidos
como SQL e, apresentará aplicações e os tipos existentes.

Também, serão apresentados os principais modelos de bancos de


dados não relacionais, as suas formas de tratamento, alguns aplicativos
utilizados para gerenciamento de bancos de dados, dentre outros
conceitos importantes para que você possa adentrar nesse universo.

O mundo dos bancos de dados NoSQL é relativamente jovem e pouco


explorado. Eis mais um motivo para que você possa desbravá-lo e
se tornar pioneiro no uso dessa tecnologia, a qual tende a crescer
continuamente. Serão apresentados modelos orientados a documentos,
orientados a chave/valor, à família de colunas e, por fim, modelos
orientados a grafos.

Não pretendemos com este conteúdo esgotar o assunto, mas,


pretendemos apresentar a maior quantidade possível de informações
para que você possa, minimamente, desbravar o mundo dos bancos de
dados não relacionais.

Desejamos que você aproveite bastante este momento de estudo do


conteúdo. Que ele possa trazer insights para a sua vida, tanto acadêmica
quanto profissional, e que ao final deste curso você possa sair com um
diferencial em sua formação! Bons estudos.

5
Bancos de dados não
convencionais: introdução aos
principais modelos de dados
NoSQL
Autor: Sergio Eduardo Nunes

Objetivos

• Compreender os conceitos e as características de


bancos de dados não relacionais.

• Identificar em quais casos o banco de dados não


relacional pode ser aplicado.

• Comparar a estrutura de banco de dados relacional


com a não relacional. 0
1. Introdução aos principais modelos de
dados NoSQL

Caro aluno, no início dos anos 2000, grande parte das salas das casas
possuíam um cantinho com um desktop, com acesso à internet, que
era utilizado pelas pessoas da família. Anos depois, com a maior oferta
de internet móvel por parte das operadoras de telecomunicações e o
acesso da população a smartphones, as pessoas passaram a consumir e
gerar grande quantidade de dados.

Com isso, a forma como os bancos de dados armazenavam as


informações teve que ganhar novos moldes, pois só dessa forma seria
possível gerenciar essa quantidade massiva dos mais variados tipos de
dados em um SGBD (Sistema de Gerenciamento de Banco de Dados).

Segundo Pramod (2013), com a necessidade de gerenciamento e


tratamento de grandes quantidades de dados é que surge o termo
NoSQL. Inicialmente se deu por meio de uma aplicação feita pelo Google
em 2004, denominada BigTable, que consistia em um banco de dados
com alta performance, totalmente escalável e grande disponibilidade, de
forma que suportasse Petabytes de processamento de dados.

Após isso, em 2005, a fundação Apache lançou o CouchDB. Essa


arquitetura foi definida por JSON (JavaScript Object Notation), pois
permite um formato mais leve para as transações entre a aplicação e
o banco de dados, consulta simplificada e um modelo que permite a
configuração da taxa de processamento quando são utilizados grandes
volumes de dados.

DECANDIA et al. (2007) publicaram um artigo sobre o Dynamo, no


qual foi descrito um banco de dados baseado no armazenamento
de chave-valor. As necessidades encontradas pelo Facebook devido
ao grande volume de dados gerados, surgiram, em 2008, quando foi
desenvolvido o banco de dados NoSQL conhecido como Cassandra,

7
que posteriormente passou a ser mantido pela fundação Apache.
Finalmente, em 2009, uma empresa chamada 10Gen junto com a
Fundação Apache lançou o Mongo DB, que é um banco de dados não
relacional orientado a documentos. O sistema de banco de dados foi
escrito em C++, e a linguagem de manipulação de dados escolhida
foi o JSON.

Para que você possa compreender melhor como um banco de dados


não relacional é estruturado, vale a pena relembrar como o banco de
dados relacional é organizado. Dessa forma, observe o DER (Diagrama
de Entidade Relacionamento) representado na Figura 01.

Figura 1 – DER de banco de dados relacional

CPFEB
Telefone
Nome
Client e 1 n)
Venda Produtos

--------
f-----e
f-o
Codigo
i - o Nome
varidade

Cod_Produto
CPF_Client e
Data
Id

Fonte: elaborada pelo autor.

Nesse exemplo da Figura 1, o banco de dados apresentou três tabelas:


Cliente, Venda e Produtos. Para que que uma venda possa ser registrada
no banco de dados (BD), a tabela Venda deve possuir uma chave
primária, um número que identifique o cliente que fez a compra e
um número que identifique o produto comprado. Para isso, o BD do
tipo relacional utiliza um sistema de chaveamento (chave primária e
estrangeira), para que assim as tabelas existentes dentro do BD possam
se relacionar.

Segundo Silberschatz (2010), as chaves estrangeiras são chaves


primárias herdadas por uma tabela filha. Observe a Figura 2 para melhor
compreensão desse conceito.

8
Figura 2 – Chaves Estrangeiras

ven.i.. J ~~
~

---e Cod_Produto

CPtF_ Olien1te
O.ata
Id

Fonte: elaborada pelo autor.

Repare que existem dois campos chamados Cod_Produto e CPF_clientes,


que são, exatamente, as chaves primárias das dabelas Produtos e
Clientes. Com essa técnica, é possível recuperar informações de todos
os campos, desde que as tabelas estejam relacionadas. Perceba que
no banco de dados do tipo relacional, para que ocorra o perfeito
funcionamento, algumas regras de relacionamentos e os tipos de dados
que os campos irão receber devem estar em hamonia e normalizados.

Tais regras de modelagem de dados fazem-se necessárias em banco


de dados do tipo relacional, pois, de outra forma, pode haver um
comprometimento quanto à precisão e consistência dos dados. Observe
o exemplo no script SQL da Figura 3.

Figura 3 – Script do banco de dados relacional


1 Create table Capitão
2
3
4
5
6
lId int p rimary key ,
Nome varchar (SO ) not nall
) ;

Create table Na vio (


7 Codigo int p rimary key ,

1
8 Nome varchar (80 ) not nall ,
9 Id_Capita o char (l ) not nall ,
10 Foreign key Id_Capitao references Capitao (Id)
11 .> ;

Fonte: elaborada pelo autor.

9
No exemplo acima na tabela Capitão a chave primária Id foi declarada
para receber números inteiros. Já a chave estrangeira Id_Capitão
na tabela Navio foi declarada como char, o que possibilita que o
usuário possa cadastrar uma letra. Dessa forma, um Navio poderia
não encontrar o relacionamento correto com o Capitão e o banco
relacional acabaria apresentando uma inconsistência, devido ao erro no
desenvolvimento do banco de dados.

Caro aluno, a ideia aqui não é mostrar que o BD relacional é melhor ou


pior do que o BD não relacional, mas sim fazer você compreender em
quais casos cada um deles deve ser utilizado. Segundo Pramod (2013),
tais diferenças técnicas nos bancos relacionais e não relacionais são os
critérios que definem qual deve ser a sua aplicação. Para compreender
as diferenças técnicas, observe o Quadro 1.

Quadro 1 – Diferença técnica entre BD relacional e não relacional

Escalabilidade Consistência Disponibilidade


BD Relacional Existe a possibilidade Essa é a maior Existe garantia de
de deixar o BD vantagem do BD disponibilidade, desde
escalável, porém relacional, pois a que a demanda de
a sua projeção maior preocupação inserções, exclusões e
é complexa. está nos consultas consecutivas
relacionamentos. não sejam de
grande volume.
BD não Por não possuir Não existe Possui grande
Relacional uma estrutura com nenhuma garantia disponibilidade, pois
rigor no tipo de de consistência permite grandes
dado a ser recebido, dos dados. cargas de dados.
esse tipo de BD é
altamente escalável.

Fonte: elaborado pelo autor.

Não existe uma forma de se poder afirmar que um modelo de banco


de dados seja melhor do que o outro. O que temos, na verdade,
são estruturas diferentes, para tipos de dados específicos em
cada projeto.

10
PARA SABER MAIS
Compreender a arquitetura de banco de dados do tipo
relacional e não relacional permite que o profissional de
tecnologia da informação possa escolher a mais adequada
para o seu projeto de maneira mais assertiva.
O artigo de Fernandes e Silva (2016), intitulado Comparativo
Técnico de tecnologias de banco de dados: Relacional
e NoSQL, aborda, de forma expositiva, uma análise
comparativa entre as duas arquiteturas. E permite que se
possa compreender algumas implementações possíveis em
cada um dos tipos apresentados.

Outra característica no desenvolvimento dos BDs relacionais e não


relacionais é que o primeiro basicamente é estruturado verticalmente,
enquanto o segundo horizontalmente. Com isso, no BD do tipo
relacional a garantia da integridade dos dados se torna mais fácil de se
garantir. Isso ocorre por meio da implementação da funcionalidade do
ACID (Atomicity, Consistency, Isolation e Durability).

Segundo Toth (2016), essas propriedades do ACID devem garantir que as


transações no banco de dados sejam feitas com:

• Atomicidade (Atomicity): garante que as transações sejam feitas de


forma indivisível. Ou seja, todas as execuções devem ser feitas em
caso de sucesso, e em caso de falha nenhuma execução, mesmo
que parcial, deve alterar a base de dados.
• Consistência (Consistency): quando as transições são executadas, o
BD deve permanecer em um estado consistente, com respeito às
regras de integridade lógica e de chaveamento dos elementos.
• Isolamento (Isolation): quando se tem base dados em que mais de
um usuário tem acesso (multiusuário), deve-se garantir o isolamento
dos processos para evitar concorrências e incosistências.

11
• Durabilidade (Durability): deve ser garantido que, após uma transação
que tenha tido sucesso ao ser executada (commit), e posteriormente
ocorra alguma falha, o que foi feito não seja mais alterado.

Porém, a garantia do ACID em NoSQL é mais complexa para a sua


garantia, e é aí que surge o teorema de CAP (Consistency, Availabity e
Network Partition Tolerance – Consistência, Disponibilidade e Tolerância
a particionamento) proposto por Brewer (2000). A sua premissa inicial é
que os seguintes requisitos devem ser garantidos:

• Todos os nós devem ter a mesma versão para a garantia da


consistência.
• Todas as solicitações por uma cópia dos dados devem estar
disponíveis em um dos servidores, a fim de se garantir a
disponibilidade.
• O sistema continua com os mesmos dados e propriedades de
configurações, mesmo se estiverem em servidores diferentes. Isso
garante a tolerância no BD, pois para o usuário a localização dos
dados é indiferente.

Para melhor compreensão, o esquema conceitual do CAP é


representado na Figura 4.

Figura 4 – Postulado CAP

Disponibilidade

Fonte: elaborada pelo autor.

12
Assim, os postulados do CAP determinam que:

• Pode-se ter duas das três propriedades representadas na Figura 4,


para qualquer sistema com BD compartilhado.
• Para que ocorra a expansão de uma base de dados, deve-se optar
pela disponibilidade ou consistência, por exemplo.
• A disponibilidade é o quesito mais importante, pois impacta
diretamente na qualidade do serviço. Dessa forma, o sistema de
gerenciamento de banco de dados deve possuir mecanismos para
a sua garantia.

Com as novas necessidades do mundo moderno, no qual grande parte


da população está conectada à rede mundial de computadores de
alguma forma, surgiu a necessidade de se armazenarem diferentes
tipos de dados. Porém, o modelo relacional não atendia tais requisitos
devido às regras de sua estrutura. Daí surgiu um novo conceito
denominado NoSQL.

2. NoSQL
.Â.

No início, o NoSQL era interpretado como “Não SQL”, ou seja, oposto


ao banco de dados do tipo relacional, denominado RDBMS (Relational
Database Management System). Porém, a sua interpretação correta é
“Not Only SQL” (não apenas SQL), remetendo à flexibilidade desse tipo
de banco de dados.

Brewer (2000) define que a tecnologia NoSQL surgiu para atender a


demanda que havia no mercado em se armazenar grande volume
de dados. Porém, para isso, algumas propriedades transacionais
não seriam atendidas, mas, em contrapartidada, havia um ganho de
desempenho e tolerância a falhas.

13
Essas características não chamaram a atenção apenas de profissionais
de tecnologia da informação. Empresas como a Amazon, Google e
Facebook viram nessa arquitetura uma solução altamente escalável,
o código livre, e a capacidade de armazenar, processar e gerenciar
grandes volumes de dados, de tipos variados.

Segundo Toth (2016), o NoSQL possui quatro tipos de estruturas, cada


uma delas atendendo a propósitos específicos:

Chave-valor

Na técnica conhecida como Chave-valor, os algoritmos e matrizes


recebem uma programação que permite fazer busca dos registros
compartilhados. A sua forma de atuação é bem simples, pois os objetos
armazenados recebem um valor de uma chave, que possibilita o acesso
rápido e seguro aos dados. Basicamente, todos os objetos inseridos
no BD fazem parte da coleção de dados. O que os difere é a chave
identificadora, que deve ser unívoca. Pode ser encontrado nos SGBDs
não relacionais: DynamoDb, Couchbase, Azure Table Storage, Redis,
dentre outros.

Orientado a documentos

Esse tipo de BD é uma opção para dados semiestruturados. Quando


os registros são armazenados, eles recebem uma chave-valor. A
sua estrutura funciona da seguinte forma: existe um conjunto de
documentos e, em cada um desses documentos, existe um conjunto de
campos (chaves) e o respectivo valor do campo.

Uma característica é que utiliza JSON para fazer as suas operações,


conforme pode ser observado no script representado na Figura 5.

14
Figura 5 – Script JSON
14 {
15 Usua~io : 'Serginho' ,
16 DataPostagem : new Date ,( ' 2019-07-06' ),
17 Assunto : 'Banco de dados NoSQL' ,
_'3 Texto : 'Orientado a docurr.entos' ,
19 Come nt arios : [
20 {Us uaria : 1 voão 1 , comentaria : 'Ótima opção pa=a me~s projetas' },
21 {Us u ario : 'Maria' , comen taria : 'H'J.ito utilizado pelas empresas' } ,
22 {Usuaria : 'vosé • , comentario : 'Utilizado em alguns jogos online• }
23
24 }

Fonte: elaborada pelo autor.

Colunar

Aqui, nesse tipo, todos os registros inseridos no BD ficam alocados em


colunas diferentes. Ou seja, uma tabela com n colunas. Nesse sentido,
nem todas as linhas possuem o mesmo número de colunas. A sua
indicação é em aplicações online, nas quais o processamento analítico
também está em uma topologia web. Isso ocorre pois os dados advindos
da internet podem ser de diversos formatos, dessa forma nem todos
necessitarão do mesmo número de colunas. Alguns bancos de dados
que utilizam esse tipo, são: Hadoop, Cassandra, Hypertable, Amazon DB,
entre outros.

Grafo

Nesse tipo de BD são guardados os objetos e não os registros, como


discutido nos demais tipos. A busca pelas informações é feita pela
classificação dos vértices e arestas, representando a interconectividade,
conforme pode ser observada na Figura 6.

15
Figura 6 – Exemplo de Modelo em Grafo

Fonte: elaborada pelo autor.

Alguns bancos de dados que utilizam esse tipo são: neo4j, OrientDB,
AllegroGraph e Bitsy (Java).

2.1 SGBDs não relacionais

É claro que, com um potencial tão alto de aplicações no mercado,


diversas empresas desenvolvedoras de software iriam investir recursos
para ter uma opção NoSQL para ser implementada nas aplicações e
demais necessidades encontradas.

Isso criou um novo mercado, pois a estrutura NoSQL possui quatro tipos
(chave-valor, orientado a documentos, colunar e grafos) com cada uma
delas voltada para uma necessidade, fazendo com que o mercado de
software voltado a NoSQL disponibilizasse diversas opções que podem
ser conhecidas a seguir (serão apresentados dois SGBDs de cada um dos
tipos discutidos anteriormente).

16
Dynamo DB – NoSQL do tipo chave-valor

É um produto comercializado pela Amazon e que possui recursos como:


modo de capacidade sob demanda, suporte integrado a transações ACID,
backup e recuperação sob demanda e criptografia de dados ociosos.

Trata-se de uma ferramenta de alto desempenho que pode ser do tipo


chave-valor ou orientado a documento, conforme a sua configuração de
uso. Quanto à performance de processamento de informações, pode ser
feita 10 trilhões por dia, suportando picos de 20 milhões de solicitações
por segundo.

Muitos clientes utilizam tal tecnologia, com destaque à Lyft, Airbnb,


Sansung, Toyota, entre outros. O interesse se deu pois o banco de dados
promete baixa latência no processamento de dados, integração com IoT
(Internet das coisas), aplicativos mobile e jogos.

Quanto à parte relacionada a operacionalização em si, existe um console


de desenvolvimento das tabelas, e o gerenciamento e demais consultas
podem ser feitas por meio da linguagem Python.

Redis – NoSQL do tipo chave-valor

O significado de Redis é Remote Dictionary Server, uma característica


é que seus dados são armazenados por chave-valor, com uma
semelhança da estrutura do dicionário de dados encontrado no .net e
Java. A chave-valor utilizada pelo Redis se difere um pouco de outros
produtos semelhantes, pois pode utilizar strings, hash, list e sets
ordenados ou não.

Esse banco de dados possui algumas características peculiares: baseado


em um modelo cliente-servidor (ponto-a-ponto); não possui suporte
para o sistema operacional Windows; apesar de operar na camada de
aplicação do modelo TCP/IP, não utiliza o protocolo HTTP.

17
O grande atrativo do Redis é a compatibilidade com mais de 40
linguagens de programação, entre elas: C, Delphi, Java, Lua, PHP,
Pythons, R, etc.

MongoDB – NoSQL do tipo orientado a documentos

É um banco de dados do tipo distribuído, orientado a documentos.


Foi projetado para ter compatibilidade com aplicações em nuvem.
Tem como características: armazenagem de dados em documentos
semelhante ao JSON; mapeamento dos objetos no código da aplicação;
estrutura do banco tanto para a arquitetura distribuída; todas as versões
são livres para utilização.

Quanto às características técnicas, o MongoDB é altamente flexível,


sendo possível fazer integração com as linguagens C#, Java, PHP,
Javascript, NodeJs, Python, entre diversas outras. Ainda, pode ser
instalado e configurado em servidores Windows e Linux, com as mesmas
funcionalidades e performance.

Algumas empresas adotaram o MongoDB como banco de dados,


dentre as quais pode-se destacar: SEGA, Nokia, Adobe, Cisco, Google,
entre outras.

CouchBase – NoSQL do tipo orientado a documentos

Esse banco de dados, segundo a fabricante, foi desenvolvido para


bases de dados do tipo NoSQL em que exista aplicações críticas
ao negócio, ou seja, promete agilidade no desenvolvimento,
alta capacidade de processamento e escalabilidade. Quanto às
características técnicas, o Couchbase possui: garantia de entrega
contínua; SQL para BD JSON; baixa latência nas consultas;
desempenho consistente independente da escala; segurança de pilha
ou em camadas.

18
Devido às características técnicas, algumas grandes empresas de ponta
no mercado utilizam esse SGBD, entre elas: eBay, DirecTV, Linkedin, Sky
e Comcast.

ASSIMILE

A linguagem SQL é a base de comunicação com o banco


de dados. Grande parte dos sistemas de gerenciamento de
banco de dados relacional ou não relacional utilizam o SQL,
porém, sempre existe algumas características na sintaxe em
cada um dos bancos de dados.
Para auxiliar os profissionais da área de desenvolvimento
de software, algumas empresas disponibilizam bases de
conhecimentos, fóruns de dúvidas, documentação, ou,
ainda, treinamentos.
Um exemplo de treinamento gratuito disponibilizado é o
SGBD NoSQL Couchbase.

Cassandra – NoSQL do tipo colunar

O Apache Cassandra como é conhecido, é um BD NoSQL que promete


escalabilidade linear, tolerância a falhas, preparado para aplicações em
nuvem. Quanto as suas características técnicas, tem a capacidade de
armazenar mais de 75.000 nós, por volta de 10 PB de dados; durável,
pois a sua disponibilidade pode chegar a 99,99999% de uptime, o que
oferece a garantia de não perder dados.

O Cassandra utiliza a linguagem conhecida como CQL (Cassandra


Query Language), algo muito próximo ao SQL, como se pode observar
na Figura 7.

19
Figura 7 – Exemplo de CQL
'40 CREATE KEYSPACE IF NOT EXISTS "teste"
'41 WITH replication = { 'class' : 'Sirr.pleStrategy' , 'replication_ factor' : 1 } ;
'42
'43 CREATE TABLE "teste" . "contatos"
.g.g Id uuid ,
'45 Nome t ext ,
'46 Email tex t ,
'47 Wbat s app te x t ,
.g 8 PRIMARY REY (Id)
'49 ) ;

Fonte: elaborada pelo autor.

Existe um portfólio de mais de 1500 empresas que utilizam o Cassandra,


em destaque: CERN, Instagram, Netflix, GoDaddy, entre outras.

Hadoop – NoSQL do tipo colunar

O banco de dados NoSQL Hadoop é mais um projeto de sucesso da


Apache. Esse SGBD possui uma estrutura de processamento distribuída,
confiável e escalável, que permite uma capacidade de processamento de
dados altíssima, sendo distribuída por módulos, conforme a necessidade
do cliente, em que:

• Hadoop Common: usuários domésticos ou de pequeno escritório


(SOHO – Small Office Home Office).
• Hadoop HDFS: voltado apara aplicações que necessitam de um
sistema de arquivos distribuído.
• Hadoop YARN: um framework para agendamento de tarefas
administrativas no banco de dados.
• Submarino Hadoop: utilizado para fazer a integração entre o
Hadoop e alguma aplicação em que se precise implementar
aprendizado de máquina.

Com os módulos para diversos tipos de situações, algumas empresas


fazem o uso desse SGBD, entre elas: Royal Bank of Scotland, Yahoo,
Facebook e a companhia aéra British Airways.

20
OrientDB – NoSQL do tipo orientada a grafos

É um SGBD de código aberto, que possui um poder gráfico muito


marcante e a flexibilidade em desempenho e escalabilidade. Entre as
suas características técnicas que atraem os profissionais de banco de
dados que necessitam de um NoSQL orientado a grafos estão funções
como: configuração e ajuste no tamanho do cache; transação ACID,
segurança em camadas e diversos tipos de dados suportados. Ainda tem
como vantagem ser altamente compatível com as linguagens: PHP, Java,
Python e Gremlin.

Muitas empresas utilizam esse banco de dados quando necessitam


de uma estrutura orientada a grafos, tais como: Kyocera, Fox Sports,
Proteus, DigitalGlobe, entre outras.

AllegroGraph – NoSQL do tipo orientada a grafos

É um banco de dados gráfico presistente, moderno e com


ótimo desempenho para grafos. As características técnicas mais
marcantes, são:

• Combinação de utilização eficiente entre memória e


armazenamento.
• Suporte de recuperação de falhas, com transactions: Commit,
Rollback e Checkpoint.
• Indexação dinâmica e automática, com confirmação, para a
garantia da integridade.
• Integração com MongoDB.
• Altamente compatível com as linguagens de programação Java,
Python, Perl, Rubby, Scala. Ainda, possui vasta documentação de
suporte às linguagens citadas.

Muitas empresas e desenvolvedores utilizam e indicam tal tecnologia,


com destaque à Pfizer, Novartis, Lilly, MCNA Dental, entre outros.

21
Mas nesse momento você deve estar se perguntando: quais são as
vantagens em se utilizar um banco de dados do tipo NoSQL? Pois bem,
mais uma vez vale a pena ressaltar que nenhum modelo é superior a
outro, mas sim, mais adequado para determinados projetos.

Entre as vantagens apontadas por alguns profissionais ligados a banco


de dados, pode-se destacar:

• Boa parte dos BDs NoSQL possuem código aberto, o que


possibilita às pessoas com qualificação técnica fazer modificações
e personalização de soluções.
• Fácil implementação, pois muitos sistemas de gerenciamento de
banco de dados, que antes só instalavam o BD do tipo relacional,
hoje em dia já instalam de forma nativa uma opção NoSQL. Por
exemplo, o WAMP, que disponibiliza o MariaDB.
• Implementação multiusuário, isso abre diversas possibilidades
de topologias do tipo como sistemas distribuídos ou cluster. Mas
para isso, o administrador de banco de dados deve se atentar aos
aspectos relacionados à tolerância a falhas.
• Taxa de crecimento, esse aspecto pode ser escalonado conforme
as necessidades de negócio. Isso ocorre de forma com que nem
o desempenho da aplicação, nem o do próprio banco de dados,
possa ser afetado negativamente.
• CAP, apoia os requisitos mais importantes dentro das
características em particular de cada projeto.

Quando se trata do relacionamento entre os sistemas distribuídos e os


bancos de dados do tipo NoSQL, Moura e Casanova destacam que:

Os sistemas de gerenciamento de banco de dados distribuídos


contribuem significativamente no aumento da produtividade de aplicações
que trabalham com dados de tipos e tamanhos diferentes. Isso se dá
pelo fato de simplificar as tarefas de compartilhamento dos recursos
geograficamente distribuídos.

(1999, p. 14)

22
Porém, apesar de todas as vantagens apontadas até o presente
momento, quando se tem a necessidade de banco de dados do tipo
NoSQL ocorrem algumas perdas de funcionalidades. Em comparação
às funções encontradas na maioria dos sistemas de gerenciamento
de banco de dados do tipo relacional, alguns aspectos deixam de ser
utilizados, entre eles podemos destacar: as consultas que utilizam
join, group by, order by; as transações ACID são feitas com base no
CAP; a falta de suporte a NoSQL por parte de algumas ferramentas de
desenvolvimento.

Com base no exposto, o NoSQL já é uma realidade nas empresas que


necessitam de um sistema de gerenciamento de banco de dados que
tenha suporte a múltiplos tipos de dados, arquitetura para sistemas
distribuídos, altamente escalável e que tenha uma capacidade de
processamento de dados robusta. É possível encontrar diversas soluções
no mercado de software de banco de dados NoSQL, para diversos tipos
de demanda.

TEORIA EM PRÁTICA

O Brasileirão é um campeonato de futebol em que 20 times


se enfrentam no estilo casa/fora e os times se enfrentam
duas vezes nas 38 rodadas, sendo uma no seu estádio e a
outra partida no estádio do adversário. O time que possui
o maior número de títulos é o Palmeiras (10 títulos), e
esse campeonato é considerado um dos mais difíceis por
técnicos, jogadores e comentaristas esportivos.
Devido à popularidade do esporte no Brasil, surgiram
alguns aplicativos em que o usuário acumula uma
pontuação rodada a rodada, e ao final são distribuídos
alguns prêmios. Um exemplo está em um famoso aplicativo

23
no qual o usuário deve escalar um time, onde pode ser
escolhido um jogador por posição, e de qualquer clube.
Conforme o desempenho em campo do jogador escalado
pelo usuário do aplicativo, são acumuladas as pontuações.
Os pontos são contados da seguinte forma: quando
o jogador escalado tem um bom desempenho, a sua
pontuação aumenta (gol, drible, passes, etc), e em caso
de faltas, cartões e gol contra, são retirados pontos do
jogador. Ao final da rodada é feita a somatória de pontos da
escalação feita pelo usuário, e ao longo do campeonato é
feito um rankeamento com as melhores pontuações.
Com base no cenário explicado dos aplicativos de
campeonato brasileiro, qual o tipo de banco de dados
NoSQL indicado para estruturar os dados? Chave-valor,
orientado a documentos, colunar ou grafos?

VERIFICAÇÃO DE LEITURA

1. Existem dois tipos de arquiteturas de banco de dados,


o relacional e o não relacional (NoSQL), cada um deles
dirigido para aplicações diferentes. Com base no
exposto, analise as afirmativas a seguir:

I. No banco de dados do tipo relacional a escalabidade é


facilmente configurada com alguns comandos.

II. No banco de dados do tipo não relacional, não existe


garantia de consistência dos dados.

24
III. A disponibilidade tanto em banco de dados relacional,
quanto não relacional, é a mesma.

Assinale a alternativa correta.

a. Somente a alternativa I está correta.


b. Somente a alternativa II está correta.
c. Somente a alternativa III está correta.
d. Somente as alternativas I e II estão corretas.
e. Somente as alternativas II e III estão corretas.

2. Os dados são gerados a todo momento, seja em uma


simples navegação em uma rede social, aquele usuário
que está pesquisando vagas de emprego, ou, ainda, o
envio de planilhas de uma matriz para uma filial.

Para armazenar todos esses dados, dos mais variados


tipos, foi necessário desenvolver um banco de dados que
atendesse a essas características e ainda preservasse os
parâmetros importantes característicos aos sitemas de
gerenciamento de banco de dados, e é aí que surge o
conceito de NoSQL.

Com base nisso, assinale a alternativa com o nome do


tipo de banco NoSQL em que nas tabelas as linhas não
possuem o mesmo número de colunas.

a. Relacional.
b. Colunar.
c. Orientado a documentos.
d. Valor-chave.
e. Grafos.

25
3. Uma escola de cursos preparatórios para certificação
de redes deseja utilizar um banco NoSQL para que seja
possível fazer uma análise de mercado para direcionar
as propagandas aos prováveis alunos.

Para isso, será necessário coletar dados de redes sociais


separadas por três grupos, sendo eles: graduandos,
cidade em que reside, área de interesse. Após essas
coletas, os dados têm que ser relacionados entre si. Para
a necessidade encontrada no cenário descrito, o tipo de
banco de dados NoSQL indicado é o:

a. Valor-chave.
b. Orientado a documentos.
c. Colunar.
d. Grafos.
e. Relacional.

Referências
AllegroDB. Disponível em:<https://franz.com/agraph/allegrograph/>. Acesso em: 06
jul. 2019.
BREWER, E. Towards Robust Distribued. 2000. Disponível em: <https://www.
cs.berkeley.edu/brewer/cs262b-2004/PODC-keynote.pdf>. Acesso em: 07 jul. 2019.
CASSANDRA. Disponível em:<http://cassandra.apache.org/>. Acesso em: 06 jul. 2019.
CouchBase. Disponível em:<https://www.couchbase.com/>. Acesso em: 06 jul. 2019.
DYNAMO. Disponível em:<https://www.allthingsdistributed.com/files/amazon-
dynamo-sosp2007.pdf>. Acesso em: 06 jul. 2019.
MariaDB. Disponivel em:<http://www.wampserver.com/en/>. Acesso em: 06
jul. 2019.
MongoDB. Disponível em:<https://www.mongodb.com/>. Acesso em: 06 jul. 2019.
OrientDB. Disponível em:<http://www.orientdb.com/docs/last/>. Acesso em: 06 jul. 2019.
PRAMOD, J; FOWLER, M. NoSQL ESSENCIAL: Um guia conciso para o mundo
emergente da persistência poliglota. São Paulo: Novatec, 2013.

26
PHYTON. Disponível em:<https://www.python.org/>. Acesso em: 06 jul. 2019.
REDIS. Disponível em:<https://redis.io/>. Acesso em: 06 jul. 2019.
SILBERSCHATZ, A. Sistema de banco de dados. Rio de Janeiro: Elsevier, 2010.
TOTH, Renato Molina. Abordagem NoSQL–uma real alternativa. Universidade
Federal de São Carlos, 2016. Disponível em: <https://dcomp.sor.ufscar.br/verdi/
topicosCloud/nosql_artigo.pdf>. Acesso em: 07 jul. 2019.
Treinamento CouchBase. Disponível em:<https://learn.couchbase.com/
store?utf8=%E2%9C%93&ss=1&ct=78327&commit=Filter>. Acesso em: 08 jul. 2019.

► Gabarito

Questão 1 – Resposta: B
Resolução: a primeira afirmativa está incorreta, pois no banco do
tipo relacional a configuração e planejamento da escalabilidade é
difícil de se fazer, mas ainda assim é possível.
A segunda afirmativa está correta, pois o banco de dados NoSQL
não necessita de consistência dos seus dados, porque não são
necessários relacionamentos.
A terceira afirmativa está incorreta, pois devido à arquitetura ser
diferente nos dois tipos de banco de dados, a disponibilidade pode
ser diferente, conforme a taxa de processamento.
Questão 2 – Resposta: B
Resolução: no banco de dados NoSQL do tipo colunar, todos os
registros inseridos no BD ficam alocados em colunas diferentes.
Dessa forma, algumas linhas não possuem o mesmo número de
colunas que outras. Esse tipo de banco de dados é comumente
encontrado em aplicações online.
Questão 3 – Resposta:D
Resolução: no banco de dados NoSQL do tipo grafos, a busca
pelas informações é feita pela classificação dos vértices e arestas,
representando a interconectividade. Nesse caso, temos três
grandes grupos que necessitam ser interligados para que possam
gerar as informações desejadas.

27
Modelo de sintaxe XML e JSON
Autor: Sergio Eduardo Nunes

Objetivos

• Identificar os componentes e as suas respectivas


funções nas linguagens de manipulação de dados.

• Compreender as características da linguagem de


marcação XML, bem como a sua sintaxe.

• Entender as características da linguagem JSON, bem


como a sua sintaxe.
1. Introdução

Caro aluno, as linguagens naturais, que são aquelas utilizadas pelos


seres humanos, possuem regras e formatos diferentes, conforme a
nação. Em alguns casos, uma mesma língua pode apresentar sutis
diferenças, como é o caso da língua portuguesa falada no Brasil,
Portugal, Angola, etc. Isso faz com que tenhamos variações dentro de
uma mesma estrutura linguística.

Na tecnologia da informação, o comportamento das linguagens não


é muito diferente do cenário encontrado nas linguagens naturais.
E, quando o assunto é relacionado a banco de dados, também são
encontradas formas de se escrever uma sintaxe a fim de se manipular
dados em uma estrutura. Embora o SQL seja uma linguagem que
permite a interação com o banco de dados, existem algumas variantes
com estruturas bem diferentes, como o XML (Extensible Markup
Language) e o JSON (JavaScript Object Notation).

Tais linguagens são utilizadas para manipulação de banco de dados (as


sintaxes utilizadas em banco de dados são linguagens não procedurais)
especificamente em estruturas de banco de dados não estruturados
(NoSQL), e seguem algumas regras, assim como aquelas encontradas em
qualquer linguagem de programação.

Contudo, essas formas de se comunicar com o Sistema de


Gerenciamento de Banco de Dados (SGBD), como vai ocorrer a interação
do XML e JSON com as linguagens de programação (Java, PHP, Python,
etc), permitem que se estabeleçam padrões de representação dos dados
em banco de dados não estruturados.

Para isso, Vieira et al. (2012) definem que as estruturas de dados são
classificadas como:

29
• Dados Estruturados: são banco de dados organizados com
obediência às linhas e colunas. Isso é possível, pois as informações
são armazenadas em uma estrutura na qual as colunas são
nomeadas, deixando bem claro o tipo de dado que poderá ser
inserido. Para uma melhor compreensão, observe o script SQL
(Structured Query Language) representado na Figura 1.

Figura 1 – Script SQL


7 - create table tbl _ u se r {
e Id int not null primary lk!ey a u to increment ,
9 Nome varcha.r i(SO ) not null ,
10 Se nha. varchar ( 32 } not null
11 ) ;

Fonte: elaborada pelo autor.

Nesse exemplo, fica evidente que o Id é numérico do tipo inteiro, o


nome está limitado a 50 caracteres, e a senha está limitada a números,
letras e caracteres especiais com tamanho máximo de 32 elementos.

• Dados não estruturados: a estrutura interna desse tipo de SGBD


não é passível de indexação. A sua seleção, análise e interação são
mais difíceis devido a essa grande flexibilidade de tipos de dados,
sendo a característica mais marcante dos bancos de dados não
relacionais (NoSQL).
• Dados semiestruturados: nesse tipo, os dados são estruturados
como nos bancos de dados relacionais, porém, devido às chaves
(primária e estrangeira) utilizadas para definir a hierarquia
dos conteúdos, são necessárias as linguagens que permitam a
sua manipulação. Entre as linguagens mais utilizadas pode-se
destacar: XML, JSON, BSON e YAML.

Por meio das classificações nas estruturas de dados, o profissional


de banco de dados poderá compreender qual a linguagem, o SQBD
apropriado e a estrutura necessária para se garantir que as tratativas
e manipulações feitas nas bases de dados terão os resultados

30
esperados. Ainda que em alguns projetos exista a possibilidade, devido
à característica dos dados, de se optar por mais de um tipo de estrutura
de dados, fica a critério do administrador do banco de dados determinar
qual dos tipos se encaixa melhor nas necessidades encontradas.

Nesse contexto, existe uma variante dos tipos de dados, que são os
metadados. Rêgo (2013) define que são estruturas encontradas em
banco de dados, que descrevem a estrutura e os significados dos dados.
Basicamente, eles visam acrescentar informações aos dados, podendo,
de alguma forma, contribuir para que a estrutura fique mais organizada.
Os metadados são utilizados pela técnica de XML, e permitem, por meio
das Tags, definir o tipo de dado que está sendo manipulado.

Para melhor compreensão da aplicabilidade dos metadados em cases


encontrados no dia a dia, observe a Figura 2.

Figura 2 – Tipos de Metadados

M etada dos

~ ~
Caráter Técnico Caráter de Negócios

Fonte: elaborada pelo autor.

Ainda, Rêgo (2013) define que os metadados são classificados quanto ao


seu tipo, e são determinados como:

• Metadados de caráter técnico: fornecem aos desenvolvedores


e administradores de banco de dados, permitem acesso às
informações contidas no dado, e o seu respectivo tipo.

31
• Metadados de caráter de negócios: voltado à geração de relatórios
com a saída correta, como também na transformação de dados
em informações.

PARA SABER MAIS


Os metadados estão presentes na vida do usuário mais
do que se possa perceber. Certamente, se você já postou
alguma foto em uma rede social, tais fotos podem revelar
mais informações do que deveriam, e isso está diretamente
relacionado à aplicação dos metadados pelas redes sociais.
Para saber mais sobre o assunto leia o artigo intitulado
“Metadados: como as fotos online revelam mais do que
deveriam na internet”, de Garrett (2017).

Com isso, será possível compreender qual a função do XML e o JSON


para as bases de dados não estruturadas, e como as respectivas sintaxes
são utilizadas para a manipulação dos dados.

2. Linguagem XML e a sua sintaxe

O surgimento do XML (Extensible Markup Language) ocorreu


paralelamente à evolução da internet. Trata-se de uma linguagem de
marcação que foi derivada do SGML (Standard Generalized Markup
Language – Linguagem extensível de marcação genérica). A sua primeira
versão foi publicada em 1997 pela W3C (2019).

Incialmente, a comunidade de desenvolviemnto e científica acreditava


que o propósito do XML era substituir o HTML. Porém a intenção era
suprir as limitações encontradas no HTML quanto ao tratamento dos

32
dados. Com a sua evolução, foi possível perceber que a linguagem se
tratava de uma ferramenta eficiente e estruturada para a manipulação
de dados provenientes da rede mundial de computadores.

Segundo Berthold (2004), diversas áreas de negócios, política e


tecnologia da informação discutem e enxergam o potencial de
aproveitamento da massa de dados da internet, transformando-as em
informações úteis. Em caráter técnico, isso é possível, pois a utilização
do XML permite o tratamento dos metadados, principalmente daqueles
advindos da internet. O XML, desde a sua primeira versão, apresentou
algumas outras características técnicas:

• Segurança: as atividades de manipulação de dados certas vezes


podem necessitar de segurança. Os elementos XML quando
utilizadas as chaves simétricas ou assimétricas ajudam a criar um
ambiente seguro.
• Componentes: as suas ferramentas permitem criar mecanismos
de análise de dados eficiente, por meio de uma linguagem
de marcação.
• Processamento: a simplificação de sua estrutura faz com que a
taxa de processamento não fique alta, mesmo quando existam
diversas operações sendo executadas ao mesmo tempo.

ASSIMILE

As linguagens de marcação são aquelas que definem um


conjunto de regras para um formato legível, por meio
de símbolos, tags e palavras reservadas, que têm como
capacidade permitir a leitura por um interpretador e
representar as informações de forma compreensível
ao usuário.

33
A sintaxe utilizada pelo XML é baseada no mesmo conceito do
HTML. Consiste em utilizar tags, tornando, assim, uma ferramenta
útil para diversas soluções, pois tem algumas características
interessantes para a área de tecnologia da informação, conforme
apontadas a seguir:

• Extensão: o XML permite ao desenvolvedor criar as próprias


tags com qualquer idioma, sem que se necessite de alguma
adaptação.
• Armazenamento: o XML é responsável pelo armazenamento dos
dados, não sendo a sua função cuidar da sua representação.
• Padrão público: a W3C, que foi a responsável pelo
desenvolvimento do XML, determinou que este fosse de padrão
aberto para o desenvolvimento e utilização.

Segundo Berthold (2004), o XML é uma linguagem de marcação que


tem a capacidade de interação com banco de dados não relacional,
possibilitando ao desenvolvedor organizar os dados da melhor forma,
isso devido às características do NoSQL. Essa grande flexibilidade faz
com que um documento XML possa expressar qualquer tipo de dado.
Observe um exemplo de um script XML para organizar uma agenda
telefônica, representado na Figura 3.

Figura 3 – Script XML

2 ? xml v ersion = 11
1.0 11 ?
3 - <cliente- i:nfo>
'4 <nome>Sieriginho Nun es·< / name>
5 <empresa>Kroton < / empresa>
6 ·< whtas> ( 99 ) 99999-9999< / whtas >
7 < / cliente- infa>
Fonte: elaborada pelo autor.

34
Assim como qualquer outra linguagem, o XML possui regras de sintaxe,
estruturadas conforme apresentado na Figura 4.

Figura 4 – Estrutura da sintaxe XML

Declaração XML Referências

Tags Texto

~ - - -A-tr-ib-ut-0s
---
i
/
- - ~ 1·

Fonte: elaborada pelo autor.

Com base na estrutura paresentada na Figura 4, compreenda a função


de cada uma das partes que compõem a sintaxe XML:

Declaração XML

Observe na Figura 3 (linha 2) a seguinte expressão “<?xml version


= “1.0”?>”. O documento XML possui a declaração da versão, sendo
também possível inserir a codificação, conforme as regras de escrita.
Para utilizar a configuração nos padrões de escrita do português-
brasileiro, deve ser utilizado o UTF-8. Dessa forma, a declaração XML
completa seria expressa como: “<?xml version = “1.0” encoding = “UTF-
8”?>”. Existem algumas regras na declaração XML:

• O XML faz distinção entre letras maiúsculas e minúsculas, portanto


a forma correta para utilizar a tag é xml.
• A declaração deve ser a primeira instrução do documento.

35
Referências

Trata-se de um artifício que o XML possui, no qual é possível adicionar


uma marcação adicional ao documento. As referências são iniciadas pelo
caractere reservado &, e devem ser finalizadas por ponto e vírgula (;).
Sendo que as referências são divididas em dois tipos:

• Referência de entidade: são utilizadas para evitar ambiguidade


com alguns símbolos; por exemplo, como o XML utiliza os
símbolos <> para abrir e fechar as TAGs, se fosse necessário
comparar duas variáveis (a > b, a maior do que b), como faríamos?
Para sisso, são utilizadas as conhecidas como referências de
entidade, demonstradas a seguir:
• Ampersand (e comercial): &amp.
• Single quote (aspas simples): $apos.
• Maior do que: &gt.
• Menor do que: &lt.
• Aspas duplas: &quot.
• Referência de caractere: é uma forma de representação de
letras, símbolos e demais caracteres. Deve ser representado no
seguinte formato: &#83; O # seguido de um número representa
um código Unicode. No exemplo, #83 representa a letra “S”.

Texto

Uma particularidade do XML é ser case sensitive, ou seja, diferencia


maiúsculas de minúsculas. Os espaços em branco e quebras de linhas
são ignorados. Além disso, as palavras reservadas e referências não
podem ser utilizadas textualmente como tags. Por exemplo:

<version>exemplo

</version>

36
Tags

Os elementos que constituem a estrutura do XML são representados


dentro dos símbolos de menor e maior <>. Cada elemento aberto
deve ser fechado por meio de </>. Os elementos podem ter
elementos filhos associados ao elemento pai (conhecido como
elemento raiz). Essa estrutura pode ser observada na Figura 5, que
apresenta um script em XML escrito para enviar mensagem para um
grupo de alunos.

Figura 5 – Elementos XML


9 v e:rsion = 11 1.0 11 ' :
10 - <mensagem>
11 <para>Grnpo de a1unos </ para>
12 <de>Serginho Nu:nes< / de>
13 <assunto>Re.cado ! < / assunto>
14 <te xt o>Vamos e ,s to.dar NoSQL???-</ texto>
15 </ mensagem>

Fonte: elaborada pelo autor.

Dessa forma, o documento XML da Figura 5 foi estruturado como:

<raiz>

<filho_1>...</filho_1>

<filho_2>...</filho_2>

<filho_3>...</filho_3>

<filho_4>...</filho_4>

</raiz>

Um elemento pai pode ter tantos elementos filhos quantos


necessários.

37
Independentemente de qual for a linguagem de programação escolhida,
todo e qualquer desenvolvedor sabe da importância em se comentar
um código. Isso faz com que as partes que compõem um programa
possam ser identificadas e entendidas por qualquer desenvolvedor,
facilitando assim novas implementações, correções e manutenções. No
XML, a sintaxe para esse fim é: <!— Comentários —>. Um exemplo pode
ser observado na Figura 6, onde no script da Figura 5 foram inseridos
comentários para identificar e entender as linhas da programação.

Figura 6 – Comentários em XML


9 " xml v ersion = "1. O" ?>
10 < ! --Essa linha representa um comentário-->
!! - <mensagem>
12 <para>Grupo de alunos</ para>
!3 <de>Serginho Nunes< / de> < ! --Norr,e do re:n:ecence -->
B <assunt o>Recado! </ assunto>
15 <tex to>Vamos estudar NoSQL???</ tex to> <!--Linha da mensagem-->
'.!.6 </ mensagem>

Fonte: elaborada pelo autor.

Os comentários no XML possuem algumas restrições:

• Não podem ser inseridos antes da declaração do XML.


• Não podem ser aninhados.

Atributos

Os atributos são propriedades encontradas nas Tags, podendo apresentar


mais do que uma propriedade de um elemento XML. Por exemplo:

<atributos profissão = “Professor” site =”http://www.serginhonunes.com.


br” disciplina = “Banco de dados não relacional (NoSQL)”>

Serginho Nunes

</atributos>

38
Para isso, algumas regras devem ser seguidas:

• Um mesmo atributo não pode ser utilizado mais do que uma vez
em uma mesma tag.
• Case sensitive, ou seja, diferencia maiúsculas de minúsculas.

DTD – Document Type Definition

Segundo Berthold (2004), a sintaxe XML exije uma declaração do tipo de


documento. Isso faz com que sejam acordadas as regras gramaticais e
a estrutura do XML utilizada no documento. A fim de se compreender a
sua sintaxe, observe a Figura 7.

Figura 7 – Sintaxe DTD

1 - k! DOCT YPE e l e me n to DT D inden t i f i cai.d or


2 [
3 decl a r ai.çãa _ 1
4 d e c l arai.çãa_ 1
5 d e c l arai.çãa_ n
6 ]

Fonte: elaborada pelo autor.

As partes que compõem o DTD têm as seguintes funções:

• A expressão <!DOCTYPE inicia um DTD (linha 1), e o símbolo > faz


o fechamento (linha 6).
• Declaração do subconjunto interno (lista opcional de declarações)
é feita dentro dos colchetes [ ] (linhas 2 e 6).
• O identificador do DTD define o tipo de documento e o caminho
do arquivo, podendo esse ser utilizado de duas formas:
• DTD Interno: quando é utilizado o nome do documento
ao do elemento DOCTYPE, refere-se a uma associação ao

39
próprio documento. Ou seja, não ocorre nenhuma chamada
de um arquivo externo.
• DTD Externo: quando o elemento do DOCTYPE possuir
a palavra reservada SYSTEM “nomeDocumento.dtd”,
significa que está ocorrendo uma referência para um
documento externo. Isso é similar à referência às folhas de
estilo CSS para HTML.

Para uma melhor compreensão de uma estrutura completa, observe


a Figura 8.

Figura 8 – Estrutura XML completa


<: xm!. v e rsion= 11 1.0 11 ? >:
2
3
l<' OOCTYPE
email [

'4 < !IELEMENT me n sagem (para, de,assunt o ,texto) >


5
6 LEMENT pa.r a (#PCDAl'A )
7 LEMENT de (;\:PCDATA) >
LEMENT assunto ( #PCDAI'A)
9 LEMENT texto ( #PCDAl'A) >
10
11 ]>
_2
13 - <aviso>
.'.!.4 <para.>Grupo de alunos< / para>
~5 <de>Serginho Nunes</ de>
16 <assunto>Recado! </ assunto>
17 <text o>Vamos estudar NoSQL???< / texto>
º </ aviso>

Fonte: elaborada pelo autor.

Como se pode observar, o tipo desse documento é e-mail, e se trata


de um DTD interno. Nas linhas 6 a 9 são declarados os elementos e
seus respectivos atributos. Se, caso a necessidade fosse chamar um
DTD externo, somente a linha 2 seria alterada, conforme exemplo
demonstrado na Figura 9.

40
Figura 9 – DTD extreno
!<"? xml ve:::sion = 1 1 1. O 1 1 ?~
~ < ! DOCTYPE S Y STEM "' e x e mp l aEx t e r :n.o . dt ~ "

Fonte: elaborada pelo autor.

Para testar os scripts XML desenvolvidos nos exemplos demonstrados é


possível fazer diretamente no navegador de internet, da seguinte forma:

• Após editar o arquivo XML, salve com a extensão .xml.


• Com o navegador aberto, clique, segure e arraste o arquivo para
uma aba no navegador de internet. O arquivo da Figura 8 foi
apresentado como na Figura 10.

Figura 10 – Saída XML

This XML file does not app earr to have any style infonnartion

Y <aviso>
<para>Grupo de alunos </para >
<de>Ser gi nho Nunes</de >
<assu nto >Re cado !</ ass unto>
<texto>Vamos es t uda r NoSQL???</ texto>
</a viso>

Fonte: elaborada pelo autor.

Caro aluno, os exemplos dados até o presente momento dão uma


boa visão a respeito da aplicabilidade do XML e da extrutura de sua
sintaxe. O XML, quando utilizado em bancos de dados do tipo não
relacional, por ter uma flexibilidade de aumentar a quantidade de
campos, sem aumento na taxa de processamento, faz com que se
mostre uma ferramenta de fácil implementação. Outra vantagem
encontrada é a sua vasta documentação disponível nos fóruns e sites
especializados.

41
3. Linguagem JSON e a sua sintaxe

O JavaScript Object Notation, conhecido como JSON, é mais uma


das ferramentas para manipulação de dados mais utilizadas pelos
desenvolvedores e profissionais ligados a banco de dados. Ele possui
um formato leve para troca de dados e uma estrutura muito simples de
ser lida. As suas cacarteristicas fizeram com que se tornasse bastante
presente nas aplicações web.

Segundo Bassett (2015), assim como o XML, no início dos anos 2000 as
aplicações web começaram a tomar outros rumos. Naquela época, as
execuções eram feitas do lado do servidor (server side) e isso deixava as
interações lentas e ineficientes, pois, a cada interação, era necessário
carregar a página inteira novamente. Para solucionar esse problema
surgiu o JavaScript, que permitiu que os dados fossem carregados e
manipulados diretamente do lado do cliente (front side).

Mais adiante, Douglas Crockford (desenvolvedor e empresário norte-


americano) desenvolveu um subconjunto de expressões baseadas
em JavaScript que nomeou de JSON. O intuito era ter uma linguagem
fácil para as pessoas lerem e de fácil interpretação por parte dos
navegadores de internet. Logo após o lançamento da sua primeira
versão, os desenvolvedores web iniciaram uma migração de XML para
JSON em suas aplicações.

Inicialmente, o JSON foi definido por meio das chamadas Força-Tarefa


(termo utilizado pela IETF). O grupo de engenheiros da IETF descreveu a
respeito das especificações do JSON na RFC 7159 (BRAY, 2014).

A popularidade do JSON contribuiu para que diversos sistemas de


banco de dados desenvolvessem suporte nativo, entre eles podem-
se destacar:

42
Para Sistemas de Gerenciamento de bancos de dados
relacionais:

• O MySQL passou a permitir operações JSON a partir da versão 5.7


no ano de 2015. A sua documentação completa está disponível no
site dev.mysql.com.
• Já a versão em cluster do MySQL, chamada MySQL NDB Cluster, só
disponibilizou suporte a JSON na versão 7.5.2, em 2016. Houve um
grande salto ao haver suporte JSON a colunas, funções e índices.
Inicialmente, havia uma restrição a 3 colunas JSON por tabela.
• Outro caso de suporte ao JSON é o PostgreeSQL. O suporte surgiu
na versão 9.3 em 2013. Os recursos permitiram a desenvolvedores
a indexação de expressões regulares com integração a banco
de dados. A sua documentação completa está disponível no site
postgresql.org.

Para Sistemas de Gerenciamento de bancos de dados não


relacionais:

• O MONGODB utiliza documentos JSON para armazenar registros


em tabelas. O MONGODB, desde a sua primeira versão em 2007,
já oferecia suporte a operações JSON. A sua documentação
completa está disponível no site mongodb.com.
• Já o Neo4j não deixa muito claro se o suporte JSON surgiu junto
com o sistema de gerenciamento de banco de dados ou se a
funcionalidade foi adicionada nas atualizações. O fato é que
esse banco de dados não relacional possui muitas APIs web
baseadas em JSON, que permitem a interação com os dados. A sua
documentação está disponível em neo4j.com.

Embora o objeto de estudo seja os bancos de dados não relacionais,


citar o suporte de bancos de dados relacionais a JSON demonstra
que a linguagem chamou a atenção das empresas devido às suas
características técnicas, que permitiram maiores possibilidades de
interação com as bases de dados.

43
Um dos atrativos da linguagem está na sua simplicidade quanto ao
seu formato. Para isso, observe, na Figura 11, uma comparação entre
XML e JSON.

Figura 11 – Comparação entre XML e JSON


1
XML 1 JSON

!O
9 <,xml ve r sio~ "' " 1 .0" s
<regi:stro>
1
1
{,.
l
2 id" : - ,
11
12
13
14
<id>l </J.d>
<nome>Serginho Nones</ nome>
<funcao>Aotor</funcao>
</ reg1.5'tro>
1
1
3
1 l " nome n : 11 Sergir-.ho Nu!'les 11 ,
"fu."'lcaoº : "Autor" }

Fonte: elaborada pelo autor.

Segundo Bassett (2015), além da simplicidade de leitura, outros itens são


apontados como vantagens características da linguagem JSON:

• Suporte a objetos, por ser tipado.


• Velocidade maior na execução.
• Documentos com tamanho reduzido.
• Transporte rápido e seguro dos dados.

Porém, o JSON possui algumas limitações, dentre elas:

• Não possui schema, o que significa que os dados podem ser


representados de qualquer maneira, podendo ser gerados não
estruturados ou semiestruturados.
• Não permite comentários, o que exije que a documentação seja
feita em um documento externo.

Quanto às características técnicas da linguagem em si, existe uma


premissa básica de que o JSON é composto por chave/valor (key/value),
no qual as chaves devem representar os nomes dos atributos da classe,
e os valores, seu conteúdo. Para compreender essa técnica, observe o
script representado na Figura 12.

44
Figura 12 – Exemplo de Script JSON
5 - rre stu dantes'" : [
6 { "primeiroNome r1 : rr'Ayrton r1 , nul timoNome rr : rrsenna rr•} ,
7 { "primeiroNomerr : rr'A llaor' , rr'ultimoNome 'rr : rrTu ringrr },
{ r'p:rimeiroNome r1 : rr'E ob rr' , r1u1 timoNome" : ª Mairley rr}
9 ]

Fonte: elaborada pelo autor.

Para melhor compreensão, vamos analisar cada elemento presente na


estrutura da linguagem JSON apresentada na Figura 12:

1. Chave/valor: a chave está representada pela variável


“primeiroNome” (linhas 6, 7 e 8), e os seus respectivos valores são,
respectivamente: Ayrton, Allan e Bob.
2. Delimitador de objetos: os símbolos utilizados para delimitar os objetos
são as chaves “{ }”. Para cada objeto é necessário um delimitador.
3. Delimitador de array: quando se tem objetos do mesmo tipo, os
elementos são agrupados em vetores (array). Para limitar são
utilizados os símbolos colchetes “[ ]” (linhas 5 e 9).
4. Separador das chaves dos atributos (valores): os dois pontos “:”
são utilizados para separar a chave de seu valor.
5. Separador dos atributos: a vírgula “,” é utilizada para separar os
atributos de um objeto.

O JSON permite alguns tipos primitivos de dados, como pode ser


observado na na Figura 13.

Figura 13 – Tipos primitivos de dados JSON


11 - {
12 "Nome" .. " Se rginhon ,
13 r' Idade n .. 42 ,
11 r' Peso " .. 90 . 5 ,
15 " Casado " : tra.e ,
16 rrinstagiramrr : nu.11
17 }

Fonte: elaborada pelo autor.

45
Conforme pode ser observado na Figura 13, os tipos básicos são
divididos em:

• String (linha 12): são colocados entre aspas, podendo ser utilizadas
as simples ou as duplas.
• Número inteiro (linha 13): não necessita de aspas.
• Número real (linha 14): não necessita de aspas. Para representar a
parte decimal, deve-se utilizar ponto “.”.
• Booleano (linha 15): podem assumir somente os valores “True”
ou “False”.
• Nulo (linha 16): um atributo que permite receber valor nulo
(lembre-se de que nulo é diferente de zero).

Caro aluno, até aqui foi apresentada a estrutura básica da linguagem


JSON. Para fins de demonstração, na Figura 14 será demonstrada
a integração do PHP (Personal Home Page, acrônimo de Hypertext
Preprocessor) com o JSON.

Figura 14 – PHP + JSON


1 - < ?p l::.p
2 $my0bj ->nom.e = "Sergin:'1a" ;
3 $my0bj - > idade = 42 ;
4 SmyObj - > c.idade = "São Paulo" ;
5
6 $myJSON = json_encode ($my0bj } ;
í
o echo $myJSON;
9 ?>

Fonte: elaborada pelo autor.

Como podemos observar, por meio de poucas linhas de código é


possível fazer a integração de uma linguagem web como é o PHP, com
as aplicações possíveis por meio do JSON.

Caro aluno, com isso, podemos concluir que os formatos XML e JSON
permitem um suporte eficiente em bancos de dados não relacionais,

46
com uma estrutura linguística simples, próximo às linguagens HTML
e JavaScript. São de fácil implementação, com ampla documentação
disponível em seus respectivos sites oficiais, já referenciados.

O sucesso das linguagens XML e JSON pode ser facilmente observado,


pois as grandes empresas como Facebook, Google, Yahoo e Amazon
passaram a utilizá-las largamente para a manipulação dos seus dados,
principalmente quando esses estão estruturados em uma base de dados
não relacional. Mostrando, dessa forma, que o profissional de tecnologia
da informação que desenvolve aplicações web e tem uma variação de
dados em sua aplicação, deve utilizar as tecnologias quando se necessite
soluções para banco de dados NoSQL.

TEORIA EM PRÁTICA
As linguagens XML e JSON possuem uma escrita
relativamente simples em relação a linguagens mais
complexas como Java ou C. A sua integração com banco
de dados relacional ou não, e com diversas linguagens de
programação, fez com que grandes empresas de tecnologia
e desenvolvedores voltassem as suas atenções para ambas.
Em termos práticos, significa dizer que tais linguagens, por
meio de poucos comandos, permitem uma interação tanto
com a aplicação quanto com o sistema de gerenciamento
de banco de dados. Em aplicações web, ambas as
linguagens são largamente utilizadas.
Com base nisso, um site que comercializa jogos de
videogame fez uma captura de informações do que os
usuários mais buscam dentro do site, a fim de direcionar
as ações comerciais. O importante para essa tarefa é
a organização das informações como: título, console,
categoria e valor.
Com base no exposto, como essas informações ficariam nas
linguagens XML e JSON?

47
VERIFICAÇÃO DE LEITURA

1. Na área de programação, as linguagens são ferramentas


utilizadas pelos programadores na busca de soluções
encontradas no dia a dia. São diversas tecnologias
disponíveis, para as mais diversas atividades, sendo:
web, mobile, local, etc.

Devido às características técnicas do XML e a sua


sintaxe, assinale a alternativa com a classificação dessa
linguagem.

a. Linguagem de programção estruturada.


b. Linguagem de programação orientada a objetos.
c. Linguagem de marcação.
d. Linguagem para dispositivos embarcados.
e. Linguagem de folha de estilo.

2. Assim como qualquer outra linguagem de programação,


procedural ou não procedural, o XML possui
características que lhe são peculiares, conforme podem
ser observadas na Figura 15, a seguir:

Figura 15 – Trecho XML


1 DTD inde nti f icado JL
2 [
3 declaJLaçã.o_
-4 declaJLaçã.o_
5 declaJEação_
6 ] >l

Fonte: elaborada pelo autor.

Quanto à função do DTD, observe as afirmações a seguir:

48
I. O DTD faz a declaração do tipo de documento.

II. No DTD interno, os objetos devem ser estruturados


apontando para os documentos de origem.

III. O DTD externo aponta para um documento com as


características do elemento identificador.

Assinale a alternativa correta.

a. Apenas as alternativas I e II estão corretas.


b. Apenas as alternativas I e III estão corretas.
c. Apenas as alternativas II e III estão corretas.
d. Apenas a alternativa I está correta.
e. Apenas a alternativa III está correta.

3. Os desenvolvedores de software apontam a


simplicidade do JSON como uma marca da linguagem de
programação. Isso faz com que com poucas instruções,
por exemplo, consiga-se fazer uma inserção em um
banco de dados não relacional.

Com base no exposto, assinale a alternativa correta.

a. Deve ser utilizada a palavra reservada INSERT seguida


dos atributos.
b. Os atributos devem ser inseridos entre chaves,
separados por vírgula, sem a necessidade de se
declarar as chaves.
c. São separados em dois blocos de código, um com
o nome das chaves, e o outro bloco com os seus
respectivos valores.
d. Só é possível fazer inserções por meio da palavra
reservada INPUT, seguido do valor.
e. O JSON é baseado na estrutura chave/valor.

49
Referências
BASSETT, Lindsay. Introdução ao JSON: um guia para JSON que vai direto ao ponto.
São Paulo: Novatec, 2015.
BERTHOLD, Daum. Modelagem de objetos de negócio com XML: abordagem com
base em XML Schema. Rio de Janeiro: Elsevier, 2004.
BRAY, T. (editor). The JavaScript Object Notation (JSON) data interchange
format. 2014. Disponível em:<https://tools.ietf.org/html/rfc7159>. Acesso em: 22
jul. 2019.
GARRETT, Felipe. Metadados: como as fotos online revelam mais do que deveriam
na internet. 2017. Disponível em: <https://www.techtudo.com.br/noticias/2017/06/
metadados-como-suas-fotos-online-revelam-mais-do-deveriam-na-internet.ghtml>.
Acesso em: 15 jul. 2019.
RÊGO, B. L. Gestão e governança de dados: promovendo dados como ativo de
valor nas empresas. Rio de Janeiro: Brasport, 2013.
MySQL. Disponível em: <https://dev.mysql.com/doc/refman/5.7/en/json.html>.
Acesso em: 20 jul. 2019.
MongoDB. Disponível em: <https://www.mongodb.com/>. Acesso em: 20 jul. 2019.
NEO4J. Disponível em: <https://neo4j.com/developer/guide-import-json-rest-api/>.
Acesso em: 20 jul. 2019.
PostgreSQL. Disponível em: <https://www.postgresql.org/about/news/1481/>.
Acesso em: 20 jul. 2019.
VIEIRA, Marcos R.; FIGUEIREDO, Josiel M.; LIBERATTI, Gustavo; VIEBRANTZ Álvaro
M. Bancos de dados no SQL: conceitos, ferramentas, linguagens e estudos de
casos no contexto de Big Data. Cuiabá: Simpósio Brasileiro de Banco de Dados,
2012. p. 30.
W3C. Disponível em: <https://www.w3.org/standards/xml/>. Acesso em: 16 jul. 2019.

Gabarito

Questão 1 – Resposta: C.
Resolução: trata-se de uma linguagem de marcação derivado SGML
(Standard Generalized Markup Language – Linguagem Extensível de
Marcação Genérica), com características semelhantes ao HTML,
pelo motivo de apresentar abertura e fechamento de Tags.

50
Questão 2 – Resposta: B.
Resolução: a afirmativa I está correta, pois o DTD faz com que
sejam acordadas as regras gramaticais com a estrutura do XML
utilizada no documento.
A afirmativa II está incorreta, pois o XML não é uma linguagem que
permite orientação a objetos.
A afirmativa III está correta, pois, no cabeçalho, é possível fazer um
apontamento para um DTD externo.
Questão 3–Resposta: E.
Resolução: o formato do JSON é baseado no conceito de chave/
valor, como, por exemplo: {
“Cidade”: “São Paulo”,
“Ano”: 2019
}

51
Estrutura do MongoDB e Hadoop
e seus usos práticos
Autor: Sergio Eduardo Nunes

Objetivos

• Compreender acerca de bancos de dados orientados


a documentos.

• Entender a estrutura, mecanismos e sintaxes


utilizadas pelo MongoDB.

• Compreender os conceitos, mecanismos e


aplicações do Hadoop.
1. Banco de dados orientado a documentos

Quando um desenvolvedor inicia um projeto, uma das primeiras


tarefas é pensar na modelagem dos dados. Essa atividade não é
das mais fáceis, por consistir em um processo de abstração das
necessidades do negócio, no qual é preciso iniciar o mapeamento
das estruturas essenciais para organizar esses dados. Devido às
mais diferentes necessidades, surge uma nova ideia de banco de
dados, em que o seu principal conceito está apoiado na orientação a
documentos.

Porém, quando pensamos em uma base de dados sem schema,


nos remetemos à ausência de regras, inclusive na modelagem dos
dados. Mas não é bem assim. Os bancos de dados não relacionais
(NoSQL) possuem regras e tipos diferentes, que têm como intuito
atender às mais diversas necessidades encontradas nos projetos de
desenvolvimento.

Segundo Ramarkrishnan (2011), os bancos de dados orientados


a documentos devem possuir, em sua estrutura, documentos
autodescritivos, que, por sí só, descrevam qual o tipo de dado que será
armazenado em sua base. Dessa forma, esse tipo de banco deve possuir
algumas características como:

• Formato: por padrão, um registro deve permitir a inserção das


informações no interior de um documento.
• Schemas: o banco de dados deve ser livre de schemas.
• Identificadores: deve possuir identificadores universais (UID).
• MapReduce: deve proporcionar consulta de documentos por meio
de agrupamento e filtragem.
• Redundância: deve permitir dados e informações redundantes. Ao
contrário dos bancos de dados do tipo relacional, na orientação a
documentos isso não é prejudicial.

53
Para melhor compreensão do formato da estrutura de um banco
de dados orientado a documentos, observe o script desenvolvido
na Figura 1.

Figura 1 – Exemplo de Script para BD orientado a documento


1 - {
2 nid n : nl rr '
3 'í' f i rstn a me" : rr J a n es rr ,
4 r11 astn am.e " : rr Japlin rr ,
5 r' a d diress rr : {
6 rrstreet rr : " Cloud Street r, ,
rrc i t y rr : nLo s Ang e l esrr ,
"'sta te rr : r•CA'" ,
9 "'z i prl : rr 9 o s o s rr
_J } ,
11 nhobb i es rr : [ rrc a n taJt: n , rr campo :r: rr]
12 }

Fonte: elaborada pelo autor.

Como se pode perceber, a modelagem de dados está muito presente no


banco de dados orientado a documentos. Ramarkrishnan (2011) define
que os sistemas de gerenciamento de banco de dados orientados a
documentos são projetados para armazenar e consultar dados como
documentos JSON, indicado para casos em que se tenha a necessidade
de armazenar dados como catálogos, perfis de usuário e para sistema
de gerenciamento. Basicamente, este modelo pode armazenar uma
coleção de documentos. Os documentos são objetos, que devem ter
uma chave unívoca e um conjunto de campos, como: strings, listas ou
objetos aninhados.

Para a compreenssão da forma como os objetos são identificados,


observe a Figura 2 com a comparação das chaves em banco de dados
NoSQL Chave-Valor e orientado a documentos.

54
Figura 2 – Chave-Valor X Orientado a Documentos

Chave-valor Orientado a documentos

-------.~~- Estrutura encontrada


no JSON.

Fonte: elaborada pelo autor.

Podemos perceber que, no modelo chave-valor, existe uma única tabela


no banco de dados, na qual o hash é a chave para cada valor. No modelo
orientado a documentos, existe um conjunto de documentos, que são os
objetos, e, em cada documento, existe um conjunto de campos, cada um
com a sua respectiva chave (key).

ASSIMILE
Uma curiosidade a respeito do termo NoSQL está
relacionada à ausência da linguagem utilizada para a
manipulação de banco de dados, que tem como linguagem
básica o SQL. Porém, o termo inicialmente não seria esse.
A intenção era se referir à ausência de relacionamento
entre tabelas. Então, o nome escolhido foi NoREL (Not
Relational – Não Relacional). Porém, o nome NoSQL ganhou
popularidade entre os profissionais de banco de dados.

Dessa forma, poderíamos compreender como os dados são tratados nos


bancos de dados orientados a documentos, nos quais não é necessário
ter diversas tabelas para relacionar os dados, pois as informações

55
necessárias já estão contidas no próprio documento. No mercado, é
possível encontrar diversos sistemas de gerenciamento de banco de
dados orientado a documentos. Dentre os mais conhecidos, pode-se
destacar o MongoDB.

2. MongoDB

Muito popular entre os desenvolvedores e profissionais de banco


de dados, o MongoDB lida com documentos fazendo uso de uma
abordagem bidimensional, ou seja, os dados são organizados em linhas
e colunas. Outra característica é possuir o código-fonte aberto, o que
acabou atraindo grande número de profissionais da área de tecnologia
da informação. Toda essa popularidade colocou o MongoDB no topo
da lista em 2018 pela DB-Engines Ranking (2019), conforme pode ser
observado na Figura 3.

Figura 3 – Ranking Banco de Dados não relacional

DB- Engines Ranking ......


400

- MongoDB

200
+ Redi<
Cassandra
100

.. ...
] 40 + HBase
u
e
..
~ 20

8., -
Am.uon DynamoDB
N•n4J
.,,s 10

2
V-
e ~ebruarv 2018. 08-EnQones.com
20 13 2014 20 ü 2016 201/ 2018 1/11 'f'

Fonte: DB-Engines Ranking (2019).

56
Segundo Hows et al. (2015), o projeto da primeira versão do MongoDB
iniciou-se em 2007, porém só foi concluída em 2009 pela empresa
10gen, e código com licença GNU AGPL (Affero General Public License).
Já na sua primeira versão, era possível fazer a integração com as
linguagens de programação: C, C++, C#, Java, JavaScript, PHP, Python e
Ruby, demonstrando como o banco de dados possuía compatibilidade
com diversas tecnologias.

Segundo o site oficial da MongoDB, o sistema de gerenciamento foi


desenvolvido para:

• Efetuar processamento de dados orientados a documento com


alta performance.
• Ter aumento de produtividade no tratamento dos dados.
• Suporte a matrizes e objetos aninhados.
• Linguagem de consulta poderosa, com diversas expressões para
filtragem dos dados.
• Transações ACID completas.
• Suporte à computação em nuvem.

Quanto à sua linguagem, o MongoDB utiliza a estrutura do JSON. Por


meio de sua sintaxe é possível: efetuar consultas em documentos e
subdocumentos, efetuar comparações entre valores, operações lógicas,
ordenação de campos e agrupamento em consultas.

Para fins de compreensão e comparação, a cada sintaxe demonstrada a


seguir serão escritas declarações em JSON (MongoDB) e SQL.

2.1 Instrução INSERT

Comando utilizado para inserir um registro em um banco de dados.

• SQL:

57
Figura 4 – Criação de tabelas em SQL
1 - create· ta.ble t b l _ u se r (
2 I d int not uull. primary key a u t o_ inc r e ment ,
3 Nome varchar ( 50 ) not null ,
4 I dade int ,
5 Pro f i ssaa varchar ( 32 ) not null.
6 ) ;
7
insert tbl u ser values 1( 0 , "Sergiru~o" , 42 , "Professorrr );

Fonte: elaborada pelo autor.

• JSON (MongoDB):

Figura 5 – Criar registro JSON


_4 - db . doe_ u se r . ins e rt ( {
_5 I d : rr 1 rr ,
_6 Nome : rrserginho rr ,
-7 I dade : rr 4 2 rr ,
~ P rof i ssai.o : rrP ro fess o rn
19 } )

Fonte: elaborada pelo autor.

Repare que, diferentemente do SQL, no MongoDB não é necessário


criar uma base de dados (database). Ao fazer uma inserção de dados,
o documento é criado. Outra característica está relacionada à chave
primária. Caso o valor do Id for omitido (Linha 15 do Script MongoDB), o
valor da chave é gerado automaticamente. Sendo o mesmo processo do
auto_increment no SQL (Linha 2 do script SQL).

2.2 Instrução DROP

Utilizado para excluir databases ou tabelas.

• SQL:

58
Figura 6 – Exemplo de script para excluir tabela em SQL

-º d r op t abl e tbl u ser ;

Fonte: elaborada pelo autor.

• MongoDB:

Figura 7 – Excluir registro JSON

db . doe_ u ser . drop O

Fonte: elaborada pelo autor.

2.3 Instruções SELECT

Essa instrução efetua busca de registros em uma base de dados.

• SQL:

Figura 8 – Exemplo de seleção de dados em SQL

sel e ct * f r om t bl u ser ;

Fonte: elaborada pelo autor.

• MongoDB:

Figura 9 – Exemplo de seleção de dados em JSON

23 db . doc_ u 3er . f ind ( )

Fonte: elaborada pelo autor.

Nas duas linguagens também ocorre uma proximidade. Enquanto


no SQL é utilizada a palavra reservada SELECT, no MongoDB é
utilizada FIND.

Ainda, para aplicar filtros por meio da palavra reservada WHERE, temos:

59
• SQL:

Figura 10 – Exemplo de seleção de dados com condicinal em SQL


_4 sel e ct • f r om t b l u seI
15 whe r e I d = 1 ;

Fonte: elaborada pelo autor.

• MongoDB:

Figura 11 – Exemplo de seleção de dados com condicional em JSON.


25 db . d oc_ u ser . f ind {
26 ~ ~ Id : rr1 n
27
)

Fonte: elaborada pelo autor.

Nesse caso, a diferença é que os argumentos no MongoDB necessitam


ser colocados no interior do FIND.

Para realizar a contagem de registros, são utilizadas as seguintes instruções:

• SQL:

Figura 12 – Exemplo contagem de registros em SQL

17 sel e ct count ,C * ) f r om tbl u seI ;

Fonte: elaborada pelo autor.

• MongoDB:

Figura 13 – Exemplo de contagem de registros em JSON

30 d.b . dac_ u ser . caunt O

Fonte: elaborada pelo autor.

60
61
digitado a palavra mongo, que vai fazer com que o MongoDB inicie o seu
instalação e aplicar as sintaxes discutidas até o momento no MongoDB,

Observe que, ao terminar a execução do mongo, o sistema apresentou


ocaractere maior (>). Porém, ainda não é possível inciar a manipulação
demais suporte técnico) também está disponível no site oficial. Porém,

Após os serviços serem inicializados, deve ser aberto outro terminal, e

1~ ►I
O processo de instalação (manual completo com instalação, sintaxe e

[mi
gerenciamento de banco de dados possui suporte para Windows 64,

,,...,
para isso é necessário fazer o download no site oficial. O sistema de

><
-..... Q,) i:: -i::: :e
Caro aluno, nesse momento você irá compreender os processos de

<.:>
em sistemas operacionais Windows, após a instalação é necessário

-1,.) !Ci o ,,..., Q,)


oprograma responsável por iniciar todos os serviços do MongoDB.

a
<.:> <.:>
Com o prompt de comando aberto, deve-se digitar mongod, que é

V Q,)
-1,.)
....!Ci Q,)
-1,.)
Q,)
!Ci
.:7):.
::: .....::> ...::l i::~
0■ :.
o Q,)
IZ Q,)
,.,; ::
•.... Q,)
:. ....
~
Q,) <.:> "
<.:>
.....
:::)
!Ci o O.i:i
~
sr
co
Q,)
:. .., Q,) E :,, .., !Ci
.....~
•,-4 (,')
funcionamento, conforme pode ser observado na Figura 14.

Q,) N o o i::·.-<
G? M i:: ....." -1,.) -1,.) o-i:::
M Q,) -1,.) i:: :e
L'- ..::
.., ..,!Ci :: e: G? 0.l.i:i
N
.....o i:: 0.l"i::i
~
.... " !Ci
.....o &:
X
.....X
....
..
..... i::
o
..... -..,
. ....
-1,.)
!Ci
E
-1,.)
=i. .... i::
li
0.l"i::i

Figura 14 – Terminal MongoDB


:. o .i:i !Ci
t
<+.
-1,.)
o
::i:::
-.....
<.:>

-1,.)
!Ci
:.
Q,)

:::
..,Q,)
.....
o
<+.
.....e:
-1,.)
i::
Q,)

!Ci E
i:: E
Q,) o
<.:>
~
=i. E .i:i
.......... ,....,

Fonte: elaborada pelo autor.


o G? :,, -i::: .:7)
-"
i:: i:: i:: i:: .i:i .....
..,Q,) Q,) Q,) Q,) Q,) ....o i::
·• •l""I
:::
Linux 64 para diversas distribuições e MacOs.

.., -1,.) Q,) :::) -1,.) =i. -i::::::


G?
Q,)•.-<
(,') t,') e., "'
.......... Q,)•.-<
'-1,.)
.....<.:> ....
u ~ Q,)
Q,) i:: o
!Ci ....
..:: ....
-i:::
l""'"tl""'"'ll""'"'l,...-1 ::> Q E.-<
..,-,:: -i:::-i:::·'"'"i::i
i:: i:: i::<+. i::
:.
Q,) i::
o
.:7)
"
:: -i:::
i::
E o
04<
::r,
:. ..,
-1,.) !Ci !Ci !Ci !Ci
........... .., .....
.., -1,.) !Ci -1,.)
G?
.....o i::
o !Ci
!Ci <.:>
Q,)
,:i·.-< .:7) -1,.) :e E G? .:7)..::
.., e: .:7) i:: i:: !Ci e: i:: !Ci -1,.) e: ..,
..... r, ::: .....::: i::
1, ..... i::·.-<•.-<-,::•.-<
'
"t:i

...... •,.,t ...... ......


i::
:...
..,
:::

~
- .,..
..,o ....
.....
!Ci
i::
~
Q
o 't;;
....o :.::
a ....
o .:7) o
0.l...::l !Ci...::l...::l o...::i ..... -1,.) i::
:.o :::oo I O i:: :: Q,)
.... o o
.,. IZ IZIZ OI:.:: o :e <+. :.'
(,') E,-1 "f-,1 E,--1 ~ E,--1 E ,.,; .i:i ~ Q,)
0.lZ·.-<ZZ 0.lZ
-i:::o..::oo r,o
G?
U-1->UU
.... u
-i:::
Q,)
G?

.,.."
-i:::
V

....
!Ci
.....
!Ci
-
-1,.)
.....
:::

Q
o
.:7)
i::

0.l"i::i
.., .....
..:: i::
E
·'"1- (1)~-1""'"'1-
.... ..... !Ci ::> o
;:. ~
. :.ISl.i:IISllSl :ã:ISl
o IS) !Ci IS) IS)
""'M G?MM •M
IS)

.i:i
1
-i:::
::
-1,.)
i::
Q,)
E

!Ci
Q,)
.i:i
...::l
IZ
:::)

:e
-1,.)
G? "
' .....
::> IS) •.... IS) IS) -i::: IS)
....o ....:,,o .... Q,) Q,) i:7l..::
!Ci 1 "i::i 1 1 Q,) 1
..::,.., NN.-<N
Q,) sr o sr sr ,... sr
.i:IN..,NN !CIN
<.:>
Q,)
=i.
Q,)
....
..... ..,
:::
- Q,)

.:7)
.:7)
::
G?

.....1:-1->
:. Q,)
o.-<
'-1,.)
t -i::: -1,.).i:i
..... !Ci
-~
G? L'- M L'- L'- G? L'- !Ci o
..... IS) i:: IS)
' IS) IS) <+. ; -1,.) -1,.) i:; G?

iniciar os serviços.
!Ci
..:; 111S) 11 11•,-I
-1->M •M M
lt
M G? o -i::: G? -i::: º""'
E"i::i
IS) IS) IS) IS) -1,.) IS) ::r, i::
<+. " 1 li U Q li
~ ::ri ::s :::: !Ci Q,) ::r,
-NC'-NN C:N
MNM,-, ,.., Q
o ::
-1,.) i:: o o
..... ::r,:,, G? :. ..,
Q,) ....
•f,,,,11.,.-tf-,lf-,I C.".lf--,1 .:7) o :. -1,.) <+. e:,,...,
G?M ~~-,-t~ i:: .i:i o o Q,) i:: Q,)V
Q,) IS) =i. IS) IS) IS) o ::r, !Ci .., .., i:: Q,) Q,) i:: .:7)
<.:> 1 ..... 1 1 Q,) 1 :e !Ci ..... o E .... !Ci i::
!Ci co lcoco ..,co .-< G? i:: Q,):,, Q,) .i:i E·.-<
<+. IS) -i::: IS) IS) !Ci IS) Q,) =i. <.:> o .... i:: ::> ~:...:...
:. 1 i:: 1 1 "i::i 1 ....... C,? •l""I E.i:i !Ci o i:: Q,) o
Q,) 0-, ..... 0-, 0-, =i.,o-, ,.Q •.-1 :... •,-! ~ Q,) =i,..,
.., ..,_),-.,j,.Q,-.,1,-.,j :::,-.,1 !Ci"i::i.., Q,) G?"i::i -1-> =i., .....
i:: IS) 1 IS) IS) IS) i:: Q,) ..:: G? i:: <.:> E o oi::
., .,... C'l_ l_ C'l N :, N µ.j"i::i E 1- Q,) !Ci :: .,.. 1-1- o A
do banco de dados, pois é necessário criar uma pasta na raiz C:\ do
Windows com a seguinte estrutura:

• Crie uma pasta em C:\, chamada “data” (com letra minúscula).


• Dentro da pasta “data”, deve ser criada a “para db” (também em
letra minúscula).

Esse procedimento é necessário pois o MongoDB insere e organiza os


documentos na base de dados, dentro dessa estrutura. Dessa forma,
feitos os procedimentos, já é possível fazer a interação com o sistema de
gerenciamento de banco de dados orientado a documentos.

Para fins de demonstração do banco de dados MongoDB será executada


a instrução INSERT, conforme demonstrado na Figura 15.

Figura 15 – Insert no MongoDB

t > db. doc_use1•. insei-t ( {


I d: "1 ",
Nome: "Se1•9inho ",
Idade : "12 ",
P1•of issao: "P1•ofesso1•"
} )
Ui-iteResult ( { "n I nsei-ted" : 1 } )
>

Fonte: elaborada pelo autor.

Para comprovar que o documento foi criado, foi feita uma seleção dos
dados, conforme pode ser observado na Figura 16.

Figura 16 – Select no MongoDB


> db. doc_use1•. f ind O
{ "_id" : Object I d< "Sd43017b4e9ab6 7d9233e0ed "), "1 d" : "1 ", "Ho111e" : "Se1•ginho ",
"Idade" : "42", "Pl'ofissao" : "P1·ofessol'" }
>
Fonte: elaborada pelo autor.

Com isso, podemos observar que o MongoDB tem uma linguagem


simples e amigável com a qual é possível trabalhar com grandes

62
quantidades de dados. A documentação disponível pelo site oficial
é bem vasta, com uma abordagem bem didática, facilitando o
entendimento das funções mesmo quando o desenvolvedor não possui
conhecimentos técnicos a respeito da sintaxe utilizada pelo MongoDB.

Ainda é possível encontrar documentação a respeito da integração do


MongoDB com as linguagens de programação como PHP, JAVA e C#. Isso
demonstra um dos motivos pelo qual o MongoDB se popularizou entre
desenvolvedores e as empresas, que necessitam construir aplicações
que se comunicam e interagem com o banco de dados.

3. HADOOP

O mercado de banco de dados disponibiliza diversas ferramentas para


se resolver as mais diferentes demandas encontradas no mercado.
Existem soluções pagas, gratuitas, de código aberto ou fechado. Com
o passar do tempo de utilização de tais recursos computacionais, os
profissionais de tecnologia da informação acabam por ter preferência
por algumas ferramentas, como é o caso do Hadoop.

Trata-se de um software de código aberto, indicado para o


armazenamento e processamento de grandes volumes de dados. O
seu diferencial é que pode ser utilizado em cluster de computadores, o
que oferece uma maior capacidade de lidar com os dados, já que, nesse
tipo de arquitetura, o software pode viabilizar o compartilhamento de
recursos de hardware dos servidores.

Segundo Bengfort (2016), o projeto Hadoop foi inspirado no Google


File System, com o qual a intenção da empresa Google era desenvolver
o MapReduce, para simplificação do processamento de dados
aglomerados, isso no ano de 2003. Em 2006, o projeto Apache deu início
ao desenvolvimento do Hadoop, sendo lançada a sua primeira versão
em abril de 2006.

63
Já em 2010, Rob Bearden, que era o representante da Hadoop, e a
Yahoo!, firmaram uma parceria, sendo fundada a Hortonworks. A nova
empresa havia conseguido juntar os 24 engenheiros que fizeram parte
do grupo que desenvolveram a primeira versão do software.

Os desenvolvedores tinham como objetivo fazer um software que


pudesse ter alta disponibilidade, com detecção de falhas, e tudo isso
sem depender do hardware. Foi então que se tomou a decisão de que a
arquitetuta seria escalar, de servidores únicos processando em conjunto,
porém cada um oferecendo armazenamento local.

Segundo Bengfort (2016), a utilização do Hadoop para armazenamento,


gerenciamento e processamento de grandes volumes de informação
proporciona algumas vantagens, destacadas a seguir:

• Escalabilidade: por possuir uma arquitetura em cluster,


descentralizando o processamento dos dados. A sua capacidade é
na escala de petabyte.
• Desempenho: quando utilizado em cluster, não exije muito do
hardware, fazendo com que não suba a taxa de uso de memória
ou processador do servidor.
• Custo: o software é open source, porém existem soluções
personalizadas que podem ter custos.
• Confiabilidade: normalmente, os clusters são suscetíveis a falhas.
No Hadoop, quando o nó falha (referência a nó de rede, em redes
de computadores), o processamento é direcionado aos clusters
disponíveis. Os dados que estavam em trânsito também são
replicados, para evitar perdas.
• Flexibilidade: o Hadoop é altamente flexível, pois não necessita
de criação da estrutura para receber os dados (idêntico ao
funcionamento do MongoDB). Ainda, com a vantagem de receber
os dados estruturados, semiestruturados e não estruturados, de
qualquer tipo.

64
Segundo Amaral (2016), assim como qualquer outro sistema
de gerenciamento de banco de dados, o Hadoop possui
algumas peculiaridades em sua estrutura, conforme pode ser
observado a seguir:

• Estrutura de Armazenamento de Dados: os dados no Hadoop


são extremamente flexíveis. Diferentemente do que ocorre
nos bancos de dados relacionais, esse banco de dados
suporta diversos tipos de dados de forma eficiente. O seu
armazenamento pode ser estruturado em cluster, ou seja, fica
em sistemas distribuídos. A tecnologia utilizada para esse fim
foi nomeada como HDFS (Hadoop Distributed File System).
• Estrutura de Processamento de Dados: a diferença entre
o Hadoop e os outros bancos de dados está no seu
processamento. O software utiliza o MapReduce, que possibilita
o processamento de dados massivos em cluster, quando
armazenados em HDFS.
• Estrutura de Análise de Dados: essa ferrramenta permite que
as aplicações possam acessar a base de dados, permitindo a
manipulação com baixa latência. Algumas linguagens como:
PHP, Python e C# possuem vasta documentação para esse fim.

De acordo com Amaral (2016), o MapReduce é o mecanismo do Hadoop,


responsável por garantir o processamento paralelo das aplicações. Essa
técnica deve capturar as falhas, e, de forma distribuída, compartilhar
as informações para que, assim, as perdas possam ser eliminadas. As
funções do MapReduce são divididas em:

• Map: é o componente responsável por receber os dados, por meio


da chave/valor. Para isso, exije que o desenvolvedor codifique a
função do Map.
• Shuffle: esse componente deve organizar o retorno do Map, sendo
considerada a etapa de processamento em sí.

65
• Reduce: é o componente responsável pelo retorno das
informações, por meio de uma lista. Também é necessário que o
desenvolvedor realize todas as configurações necessárias para o
retorno conforme a necessidade.

Após a compreensão da estrutura do Hadoop, vale a pena conhecer


as versões disponíveis no seu site oficial, onde é disponibilizado o
download das ultimas cinco versões do software.

O Hadoop foi projetado para distribuições Linux, dentre elas: Ubuntu,


CentOs e RedHat. Existe também uma versão que pode ser instalada em
máquina virtual, baseada em CentOS.

O processo de instalação em ambas plataformas é extenso, porém


no site oficial é possível acessar a documentação completa para esse
fim. O Hadoop possibilita ao desenvolvedor fazer a instalação de duas
formas, o primeiro conhecido por Single Node Cluster: trata-se de uma
instalação na qual o servidor atua de forma autônoma e única. Toda a
carga de armazenamento e processamento fica a cargo de um único
servidor. Já o segundo modo é o Cluster, nesse tipo de arquitetura,
os computadores são colocados em paralelo, e isso exije uma
configuração na qual os servidores são configurados para que ocorra
o compartilhamento de informações e recursos de processamento de
informações no banco de dados.

O Hadoop é uma ferramenta potente para processamento de grande


massa de dados, que utiliza muitas ferramentas associadas a este
software, conforme pode ser observado na Figura 17.

66
Figura 17 – Ferramentas do Hadoop
M.,.._
.-Javad m
CAMADA DE CAMADA DE GESTÃO
VISUALIZAÇÃO ~> RESTful API
~
EAPl'S

Chef
FERRAMENTAS DE
ANALÍTICA 'ê) pentaho ~ 1111 <® FERRAMENTAS
ADMINISTRAÇÃO
~
.-
~
CAMADA DE "==}
ANALISE Spo~ cloudera
Java ..... MPJ

FERRAMENTAS
llBidoop 9'Bidoop
~-
CAMADA DE MONITORAMENTO
PROCESSAMENTO
~ .t'.,,,w,_1, "'-A.,~
CAMADA DE
ARMAZENAMENTO f mongoDB Nagios
FERRAMENTAS DE
MOTOR -.Bidoop DIAGNÓSTICO
DE EVENTOS
fM,,,J.,~

CAMADA DE
INTEGRAÇÃO (ETL)
ZooKeeper

FONTES DE
INFORMAÇÃO

Fonte: Godoi (2019).

Com isso, é possível compreender que existem diversas ferramentas


computacionais que permitem soluções para o tratamento de grandes
quantidades de dados, de diferentes tipos e formatos. A configuração
desses softwares requer conhecimentos técnicos aprofundados, de
forma que seja possível explorar os seus recursos para atender às
necessidades das empresas.

Vale salientar que as ferramentas apresentadas nessa seção


possuem vasta documentação em seus respectivos sites oficiais.
Ambos os softwares, apesar de serem open source, possuem algumas
soluções pagas, que demonstra o interesse de profissionais de
desenvolvimento devido à eficiência que é possível ter em suas
respectivas aplicações.

67
PARA SABER MAIS
Muito tem se falado a respeito de Big Data. O termo se
popularizou após a sua utilização nas campanhas eleitorais
estadunidenses, quando o então candidado à presidência,
Barack Obama, revelou que a sua equipe utilizou tais
recursos computacionais a fim de se analisar os dados e
trabalhar com informações relevantes para ganhar votos
dos delegados distritais.

TEORIA EM PRÁTICA
O mercado de games no Brasil ocupa a quarta posição no
ranking mundial de consumo, apenas Estados Unidos, Japão
e China movimentam mais esse mercado em relação ao
Brasil. Chegar ao top 10 não foi a toa, pois estima-se que
existam por volta de 3,4 milhões de gamers, movimentando
incríveis 1,5 bilhões de dólares ao ano.
Uma dificuldade muito comum entre os amantes dos
jogos eletrônicos é obter mais informações de títulos
que não são tão conhecidos, e assim poder comprar
um jogo que atenda às expectativas do consumidor.
Algumas ferramentas tentam auxiliar esse público, como:
gameplays disponíveis no YouTube, no qual um jogador
faz streaming de uma parte do jogo; blogs, que fazem
alguns resumos do jogo, e ainda, opinam a respeito dos
gráficos, jogabilidade, diversão, entre outros aspectos
relevantes aos gamers.
A fim de minimizar essa falha no setor, o MongoDB
possui uma estrutura que permite ao profissional de
banco de dados organizar os títulos dos jogos e adicionar

68
informações importantes para que os gamers possam
adquirir os jogos que realmente desejam.
Dentro desse contexto apresentado, de que forma poderia
ser estruturado um banco de dados no MongoDB, a fim
de se garantir que o consumidor de games encontrará
informações úteis antes de adquirir um título?

VERIFICAÇÃO DE LEITURA

1. Por muito tempo, os bancos de dados do tipo relacional


eram a principal opção para diversas aplicações. Com
esse tipo de banco, é possível resolver diversos tipos de
problemas e ter uma estrutura uniforme e organizada.
Porém, nem todos os cenários possuem dados que se
encaixam no tipo relacional, e é aí que surge o conceito
de banco não relacional.

Quanto às características encontradas no sistema


de gerenciamento de banco de dados orientado a
documentos MongoDB, observe as afirmativas a seguir.

I. Possui suporte a matrizes e objetos aninhados.

II. Linguagem de consulta SQL padrão.

III. Não permite transações ACID, devido à orientação a


documentos.

Assinale a alternativa correta.

a. Somente a alternativa I está correta.

69
b. Somente a alternativa II está correta.
c. Somente a alternativa III está correta.
d. Somente as alternativas I e II estão corretas.
e. Somente as alternativas II e III estão corretas.

2. As linguagens utilizadas para manipulação de dados,


em geral, possuem sintaxes que permitem desde
uma simples seleção de dados até procedimentos
armazenados. Isso permite uma vasta possibilidade de
encontrar soluções para diversos segmentos.

Assinale a alternativa com a sintaxe correta para realizar


a contagem de elementos inseridos no MongoDB.

a. nomeDoDocumento.count().
b. db.nomeDoDocumento.count.
c. db.nomeDoDocumento.count().
d. bd.count().
e. bd.nomeDoDocumento>count.

3. O banco de dados ________________ foi projetado


para processamento massivo de dados, com alta
disponibilidade e detecção de falhas. Para isso, os seus
desenvolvedores fizeram um software com arquitetura
em ____________, porém cada servidor com o seu
_____________________ local.

Assinale a alternativa que completa as lacunas


corretamente.

a. Hadoop; cluster; processamento.


b. MongoDB; paralelo; armazenamento.
c. MySQL; redundante; chaveamento.

70
d. MongoDB; cluster; processamento.
e. Hadoop; cluster; armazenamento.

Referências
AMARAL, Fernando. Introdução à ciência de dados: mineração de dados e Big
Data. Rio de Janeiro: Alta Books, 2016.
BENGFORT, Benjamin. Analítica de dados com Hadoop: uma introdução para
cientistas de dados. São Paulo: Novatec, 2016.
DB-Engines. Disponível em: <https://db-engines.com/en/>. Acesso em: 30 jul. 2019.
GODOI, D. Apache Hadoop: tudo o que você precisa saber. Cetax. Disponível
em: <https://www.cetax.com.br/apache-hadoop-tudo-o-que-voce-precisa-saber/>.
Acesso em: 02 ago. 2019.
Hadoop. Disponível em: <https://hadoop.apache.org/releases.html>. Acesso em: 01
ago. 2019.
HOWS, David; MEMBREY, Peter; PLUGGE, Eelco. Introdução a MongoDB. São
Paulo: Novatec, 2015.
MongoDB. Disponível em: <https://www.mongodb.com/>. Acesso em: 01 ago. 2019.
RAMARKRISHNAN, Raghu. Sistema de gerenciamento de banco de dados. New
York: McGraw Hill, 2011.

Gabarito

Questão 1 – Resposta: A.

Resolução: a afirmativa I está correta, pois, por ser flexível quanto à


sua estrutura, é possível ter matrizes e objetos aninhados.
A afirmativa II está incorreta, pois a linguagem de consulta
utilizada é o JSON.
A afirmativa III está incorreta, pois o MongoDB tem suporte a
transações ACID.

71
Questão 2 – Resposta: C.
Resolução: a alternativa C está correta, pois a sintaxe utilizada para
realizar contagem é a db.nomeDoDocumento.count(). Por exemplo,
se o nome do documento é carrosUsados, e a intenção é contar
quantos registros o documento carros usados possui, deve ser
usado: db.carrosUsados.count()
Questão 3–Resposta: E.
Resolução: o Hadoop suporta grandes cargas de processamento de
dados, com alta disponibilidade e detecção de falhas. O software foi
desenvolvido para utilização em cluster, porém o armazenamento é
feito no servidor local.

72
Banco de dados NoSQL: modelo
orientado a documentos
Autor: Sergio Eduardo Nunes

Objetivos

• Compreender o conceito da técnica de orientação a


documentos em banco de dados.

• Entender como foi organizada a estrutura dos


componentes de um banco de dados orientado a
documentos.

• Compreender em quais necessidades o banco de


dados orientado a documentos deve ser utilizado.
1. Modelo orientado a documentos

Certamente você já deve ter reparado a quantidade de informações


que uma nota fiscal emitida por um supermercado possui. São diversos
dados, como: cabeçalho com informações do supermercado, uma
tabela com todos os itens comprados, as observações do contribuinte
com a quantidade de impostos pagos, dentre outras informações.
Estruturar um banco de dados para armazenar os dados e gerar
tais informações não é uma técnica encontrada apenas nos bancos
relacionais.

Nos bancos de dados orientados a documentos, é possível desenvolver


bancos de dados para gerir informações como notas fiscais de
supermercados, até grandes massas de dados, e com a vantagem de
não necessitarem estar estruturados conforme as regras mais rígidas
encontradas nos bancos de dados do tipo relacional. Mas o que significa
orientar a documentos?

Segundo Anderson e Slater (2010), o conceito de banco de dados


orientado a documentos está ligado à forma como os dados são
estruturados no Sistema de Gerenciamento de Banco de Dados (SGBD),
devendo permitir a inserção de dados autocontidos ou autodescritivos.
Os documentos encontrados nos bancos de dados orientados a
documentos, por si só, já conseguem determinar a forma que será
estruturado o armazenamento dos dados.

Quanto ao armazenamento encontrado na estrutura do banco


de dados orientado a documentos, é possível ter uma coleção
de documentos em sua estrutura, porém cada documento é
representado com um objeto único, com suas características e
necessidades, podendo possuir um conjunto de campos que recebem
diversos tipos de valores, listas, ou ainda, documentos aninhados
no interior de um documento (diversos documentos em um
documento único).

74
De acordo com Anderson e Slater (2010), a falta de um schema (regra
de estrutura comum a todas linhas da tabela) permite que, ao adicionar
um novo documento, não ocorra conflito na base de dados, ou ainda,
o dado não consiga ser inserido. Alguns SGBDs permitem que o
administrador do banco de dados consulte o schema e, em alguns casos,
possa alterar um schema existente, ou ainda, criar um novo schema.

Para que você possa compreender o conceito de schema nos bancos de


dados, observe a estrutura de uma tabela representada na Figura 1.

Figura 1 – Tabela em banco de dados com schema


22 - create tab.le teste (
23 CPF bigi:nt primary key ,
24 Nome varchar ( 50 ) no,t null ,
25 Email varchar (50 ) not null ,
26 Wbatsapp varchar ( 50 ) no,t null
27 ) ;

Fonte: elaborada pelo autor.

Esse banco de dados possui schema em sua estrutura. Dessa forma, ao


tentar inserir um registro na tabela, o seguinte erro é gerado, conforme
pode ser observado na Figura 2.

Figura 2 – Erro de inserção de dados


111y:;ql)
111ysql) in:;e1•t teste ualue:; (123456?8998, "Se1•ginho", "sei-ginho@nosql.co111");
ERROR 1136 (21S01): Colu111n count doe:;n' t 111atch ualue count at 1•011 1
111ysql)
111y:;ql)

Fonte: elaborada pelo autor.

Nesse INSERT, o número do Whatsapp não foi inserido, fazendo com


que o servidor de banco de dados retorne que o número de colunas da
inserção não é o mesmo encontrado na estrutura da tabela. O mesmo
erro seria apresentado caso o INSERT tivesse uma coluna a mais.

Isso ocorreu pois o SGBD MySQL possui schema que exije que todas
as colunas devam ser preenchidas. Ainda é possível entrar com o valor

75
nulo, o que, de certa forma, garante que todas as linhas da tabela
possuam os mesmos números de colunas. Nos bancos de dados
orientados a documentos, tanto a inserção de dados com mais colunas
quanto com menos colunas seriam possíveis de serem inseridos no
banco de dados.

Na estrutura de armazenamento em um banco de dados orientado


a documentos existe uma chave indentificadora que é chamada de
Identificador Único Universal (UUID – Universally Unique Identifier).
Segundo Ramarkrishnan (2011), trata-se de uma chave que deve
identificar um registro univocamente, e esta é definida automaticamente
pelos sistemas de gerenciamento de banco de dados não relacionais.
Para uma melhor compreensão de como essa chave é utilizada, observe
a Figura 3.

Figura 3 – Identificador Único Universal


.!.
2 " i d" : ~123456789 " ,
3 " p erfil n : {
4 "nomerr : " Ser ginhon ,
5 "sobrenome" : " Nunes•r ,
6 } ,
7 " p referen c i a" : [ "Programação rr , "Esp ortes .., , "Camp ingn )
o }

Fonte: elaborada pelo autor.

Podemos observar no script JSON que a chave UUID utilizada na tabela


foi criada manualmente e foi nomeada como Id. Porém, é possível gerá-
la automaticamente, caso seja suprimida no processo de inserção de
dados. Em comparação ao SGBD relacional, é como se na coluna de
identificação do usuário o administrador do banco tenha determinado
como auto_increment, caso em que a cada nova inserção no banco é
criada uma chave primária automaticamente.

Essas características de falta de schema estão diretamente relacionadas


à velocidade de leitura dos dados. Ramarkrishnan (2011) afirma que em

76
consequência das tabelas no banco de dados orientado a documentos
serem estruturadas desnormalizadas, os dados são lidos mais
rapidamente, devido à ausência de JOINS (técnica utilizada em consultas
em múltiplas tabelas em banco de dados do tipo relacional). Para
compreender o mecanismo de consulta observe a Figura 4, referente
ao mecanismo de consulta em banco de dados relacional, e a Figura 5,
referente ao mecanismo de consulta em banco de dados não relacional.

Figura 4 – Mecanismo de consulta em banco de dados relacional

tbl_função
tbl artista
10 1 FUNÇÃO
REGISTRO NOME ID_FUNÇÂO
1000 Vocalista
001 Serj Tankian 1000
2000 Guitarrista
002 James Hitfeld 1000
3000 Baixista
003 Daron Malakian 4000
4000 Baterista

Fonte: elaborada pelo autor.

Podemos observar que na Figura 4, onde é representado o mecanismo


de consulta em banco relacional, a consulta percorre todas as linhas
das tabelas quando uma condição de relacionamento for satisfeita.
Pelo apontamento da chave primária para uma chave estrangeira, o
resultado é retornado.

Figura 5 – Mecanismo de consulta em banco de dados não relacional

tbl banda
REGISTRO NOME FUNÇÃO PAÍS SOLO
001 Serj Tankian Vocalista Líbano SIM
002 James Hitfeld Vocalista
003 Daron Malakian Estados Unidos

Fonte: elaborada pelo autor.

77
Já no mecanismo do banco não relacional representado na Figura 5, a
consulta é feita em uma única tabela em busca de informações contidas
nas linhas e colunas. Dessa forma, o número de processos executados
em uma consulta é menor no NoSQL. Um exemplo de consulta seria:
selecione o nome do artista e a sua respectiva função somente de quem
possui projeto solo.

Uma característica bastante marcante encontrada nos bancos de dados


orientados a documentos está relacionada à alta disponibilidade. Os
softwares, em sua grande maioria, oferecem a opção de fazer uma
estrutura em cluster. Para compreender como uma rede de servidores
de banco de dados em cluster é estruturada em uma topologia, observe
a Figura 6.

Figura 6 – Representação de uma topologia em cluster

Server-PT
Se t2
Servl ~PT

Server4
witch-PT
Switch 3

Server-PT
ServerO Server-PT Switch-PT
Serverl Switch2

Fonte: elaborada pelo autor.

Nessa estrutura, os servidores poderiam estar geograficamente


separados e, ainda assim, seria possível configurar um banco de dados
em cluster, com as seguintes funcionalidades:

• Armazenar as informações somente localmente, sem redundância


em outros servidores.

78
• Armazenar as informações de forma espelhada para todos os
dispositivos do cluster.
• Processar as informações de forma distribuída.

Dessa forma, se houver falha de algum dos servidores, o serviço não


sofrerá interrupções ou degradação. Essa estratégia de arquitetura em
cluster pode ser encontrada em outros tipos de bancos de dados NoSQL,
como o orientado a colunas ou chave-valor.

PARA SABER MAIS


Uma das formas de se utilizar o processamento paralelo
é na arquitetura em cluster. Esse formato também é
conhecido pela literatura como sistemas distribuídos.
Meneghetti (2013), por meio do artigo intitulado “Como
funciona um download por torrente?” publicado na revista
Super Interessante, explica de forma bem descontraída
o funcionamento da computação paralela para
compartilhamento de arquivos.

Ramarkrishnan (2011) afirma que outra característica importante do


banco de dados orientado a documentos é o seu desempenho quando
utilizado com aplicações web. Um exemplo está na catalogação de
produtos de um e-commerce, no qual as aplicações trabalham com
coleções de documentos, e a flexibilidade do armazenamento de dados
com essas características pode ser efetuada sem que ocorra qualquer
tipo de anomalia na base de dados.

Caro aluno, é claro que quando pensamos em banco de dados nos vem
à cabeça efetuar consultas a essas bases a fim de se gerar informações
úteis a determinado segmento do mercado, e se tornar um produto/

79
empresa com maior poder de competitividade. Para isso, os bancos de
dados orientados a documentos utilizam um mecanismo de consulta
conhecido por MapReduce.

1.1 MapReduce em banco de dados orientado a documentos

A fama que os bancos de dados não relacionais alcançaram nos últimos


anos muito se deu por sua estruturação em cluster. Pois isso, possibilita
o armazenamento e processamento das informações de forma
distribuída. Isso garante maior capacidade de processamento dos dados
e alta disponibilidade. Nos bancos de dados orientados a documentos,
isso é possível devido a uma função conhecida por MapReduce.

Ramarkrishnan (2011) diz que MapReduce é um processo de


programação do software de gerenciamento de banco de dados
não relacional, como o orientado a documentos. É conhecido como
MapReduce, pois:

Map: se trata do processo inical no qual os dados são agrupados e


divididos em grupos, para permitir o mapeamento.

Reduce: os dados, após serem mapeados, são possíveis de se fazer o


processo de redução, para que assim se reduza a busca e retorne os
dados consultados.

Para uma melhor compreensão do mecanismo de funcionamento


do MapReduce, tome como exemplo uma hamburgueria que possui
tempos diferentes para preparar 4 combos e utiliza uma análise da
quantidade de combos vendidos nos pedidos para projetar a quantidade
de colaboradores que seja o suficiente para atender a demanda. Para
isso, observe a Figura 7.

80
Figura 7 – Entrada e divisão no MapReduce

ENTRADA DIVISÃO

1 Combo premium, combo vegano.

Comba premium, combo vegano. 1 Combo premium .


Comba premium.
Comba kids, combo premium.
Combo bacon, combo vegano.
Comba bacon, combo bacon, 1 Combo kids, combo premium.
combo premium.

1 Combo bacon , combo vegano.

Combo bacon , combo bacon ,


combo premium.

Fonte: elaborada pelo autor.

É possível observar o processo de entrada dos dados e, após isso,


a divisão. Com isso, os dados são encaminhados aos processos de
mapeamento e junção, conforme pode ser observado na Figura 8.

Figura 8 – Mapeamento e junção no MapReduce

MAPEAR JUNTAR
Comba premium, 1. Combo premium, 1.
combo vegano, 1 Combo premium, 1.
DIVISÃO
Combo premium, 1.
Comba premium, 1. Combo premium, 1.
~ ombo premíum, combo vegano.]

1Combo premium. Combo vegano, 1.


~ -~, Comba kids, 1. Combo vegano, 1.
1Combo kids, combo premíum. Combo premium, 1.

1Combo bacon, combo vegano.


Combo kids, 1.
Combo bacon, 1.
Combo bacon, combc bacon,
Combo vegano, 1.
eombo rAmium. Combo bacon, 1.
Combo bacon, 1. Combo bacon, 1.
Combo bacon, 1. Combo bacon, 1.
Combo premium, 1.

Fonte: elaborada pelo autor.

81
Após isso, os dados são encaminhados para redução e, finalmente,
ocorre a saída desses dados. Esse processo é representado na Figura 9.

Figura 9 – Redução e saída no MapReduce

REDUZIR SAÍDA

JUNTAR

Combo premium, 1. Comba premium, 4.


Combo premium, 1.
Combo premium, 1.
Combo premium, 1.
Comba premium, 4.
Comba vegano, 2.
Combo vegano, 1. --- ~-...J Comba vegano, 2.
Combo vegano, 1. Comba kids, 1.
Comba bacon, 3.
1Combo kids, 1. ----.. .1 Comba kids, 1.
Combo bacon, 1.
Combo bacon, 1.
Combo bacon, 1.
Comba bacon, 3.

Fonte: elaborada pelo autor.

A linguagem utilizada para a leitura e escrita das estruturas nos sistemas


de gerenciamento de banco de dados orientado a documentos é a
linguagem JSON, que são estruturas linguísticas com especificações do
tipo JavaScript, que permite efetuar operações de desenvolvimento de
estruturas de dados, consultas, inserções e exclusões.

Para fins de se exemplificar a aplicação de um banco de dados orientado


a documentos, será apresentado o software CouchDB.

2. CouchDB

Caro aluno, a fim de se exemplificar todos os conceitos acerca de


banco de dados orientado a documentos, será apresentado o sistema
de gerenciamento de banco de dados CouchDB da Apache Fundation.
Segundo o site oficial disponível em CouchDB (2019), trata-se de um
servidor desenvolvido em ErLang, que tem como linguagem base para
armazenamento e consulta de dados o JSON.

82
O CouchDB foi projetado para atender demandas web, no qual o
protocolo de acesso ao sistema de gerenciamento é o HTTP (HyperText
Transfer Protocol). O funcionamento do sistema consiste em criar versões
de operações de leitura para que o processo de consulta se torne
mais ágil.

Para o controle de versões, o CouchDB utiliza uma ferramenta conhecida


como MVCC (Multi-Version Concurrency Control), na qual existem várias
versões e sempre é apresentada a versão que o banco de dados julga
ser a mais consistente. Fisicamente, os dados gravados nunca são
sobrescritos na base de dados, permitindo, assim, que a gravação dos
dados seja rápida e consistente. Caso ocorra algum tipo de problema
nesse processo, o banco disponibiliza para aplicação a versão anterior
que não apresentou problemas.

O download do CouchDB pode ser feito diretamente em seu


site oficial, sendo possível obter versões para os sistemas
operacionais: Windows, Linux e Mac. O processo de instalação em
plataforma Windows segue os mesmos passos encontrados em
qualquer programa.

Após a instalação, para se ter acesso ao servidor de banco de dados


é necessário abrir o navegador e buscar na barra de endereços o
localhost através da porta 5984. Esse processo pode ser observado na
Figura 10.

Figura 10 – Acesso ao CouchDB

C [j localhost:5984

{"couchdb" :"Wel come", "uuid":"5c5dalb30529a66c34be6506d48ecd34","version":"1.5.1","vendor":


{"version" : "1.5.1","name":"The Apache Software Foundation"}}

Fonte: elaborada pelo autor.

83
Esse processo retorna a versão do CouchDb instalado no servidor.
Para acessar a configuração do software, o painel deve ser acessado
por meio do link de endereço local: <http://localhost:5984/utils>,
digitado diretamente no navegador. Apenas para se ter uma visão geral
dos passos para se configurar o CouchDB, alguns pontos devem ser
observados:

• Existem duas versões de instalação:


• Cluster Mode: exige que, na topologia, existam diversos
servidores de banco de dados configurados para atuar de
modo distribuído (ver Figura 6).
• Single Mode: utilizado para agir como um servidor único, no
qual toda a carga de armazenamento e processamento fica
a cargo de uma única máquina.

Para escolher os modos de acesso ao banco de dados e os seus


respectivos endereços, logo nos primeiros passos de configuração deve
ser escolhido:

• Endereço padrão: o CouchDB possui uma lista de portas que


são utilizadas para o acesso a determinados serviços (ver
Quadro 1 a seguir).
• Endereço para acesso remoto em rede interna: é
um endereço de rede que deve ser reservado pelo
administrador de redes, que permite que a configuração
seja acessada via navegador, em qualquer dispositivo de
uma rede interna.
• Endereço para acesso remoto em rede pública: é um
endereço de rede pública que deve ser inserido na
configuração do servidor, de forma que possibilite
acesso remoto.

Com isso, por meio de poucas configurações é possível ter um servidor


de banco de dados orientado a documentos, no qual é possível efetuar
operações de inserção e consulta de dados. Para fins de demonstração,

84
foi desenvolvida uma aplicação em PHP que acessa uma base de dados
com os registros apresentados no script na Figura 11.

Figura 11 – Script de inserção de dados no CouchDB


10
11 " i d" : " 1 " ,
12 " Mura.lDe R e c ado s" : [
13 {
14 " Nome" : " S erginho Nunes·" ,
15 " Data" : "2 01 9 /0 8 /11 " ,
16 " R e c ado " : "PR P é mui t o massa ~.n
17 L
1: {
19 " Nome" : " S er ginho Nunes" ,
20 " Data" : "2 01 9 /0 8 /11 " ,
21 " R e c ado " : " CouchDB é o r i e n tado a d ocume n t o s . '"
22
23 1
24 }

Fonte: elaborada pelo autor.

Após a inserção dos dados no CouchDB, o PHP vai efetuar a conexão


na base de dados do CoachDB. Essa técnica pode ser observada na
Figura 12.

Figura 12 – Script PHP para conexão com o CouchDB

<?php
$dsn "http://localhost:5984/" ;
$dbuser "root '' ;
$dbpass ;

{
$pdo PDO ($dsn, $dbuser, $dbpass);

} ( PDOException $e) {
echo "Falha ao conectar a base de dados!" ;

Fonte: elaborada pelo autor.

85
Após a conexão com a base de dados, é possível fazer a consulta dos
dados no navegador por meio de uma interface web e apresentá-los em
uma tabela, conforme pode ser observado na Figura 13.

Figura 13 – Apresentação dos dados do CouchDB

,=:l Mural d'e iRecados

PARA DATA RECADO

Se rginho Nunes 11/08/19 CouchDB é orientado a documentos.

Serginho Nunes 11/ 08/19 PHP é mu ito massa!

Fonte: elaborada pelo autor.

ASSIMILE

A integração do banco de dados com as linguagens de


programação permite o desenvolvimento de sistemas,
de forma que o usuário possa inserir, excluir, alterar
e selecionar os dados. Para tal, é necessário fazer a
conexão com o banco de dados por meio da passagem de
parâmetros como o nome do usuário, a senha e o local de
armazenamento. Esse procedimento possui metodologias
que variam, conforme a linguagem de programação
escolhida.

Com isso, podemos observar que o CouchDB é um sistema de


gerenciamento de banco de dados que permite uma fácil integração
com aplicações. Apenas com o apontamento para o endereço local,
nome do usuário e senha, é possível acessar a base de dados e efetuar
uma consulta, para que seja demonstrado no front-end da aplicação.

86
A documentação disponível no site oficial CouchDB (2019) é vasta e
possibilita efetuar a consulta acerca do processo de instalação, até as
configurações do básico ao avançado. Existe, também, uma lista com
alguns comandos em JSON para se efetuar as operações no banco de
dados. A demonstração construída com a linguagem de programação
em PHP demonstra o suporte ao SGBD com uma documentação bem
detalhada e passos a serem seguidos para integração do CouchDB
com o PHP.

O banco de dados orientado a documentos demonstrou-se


extremamente flexível e altamente integrável com a maioria das
linguagens de programação. A capacidade estrutural permite o
processamento de grande massa de dados, em servidor único, e essa
capacidade aumenta se utilizado em cluster. Dessa forma, possibilita
tanto a administradores de banco de dados quanto a desenvolvedores
web, diversas oportunidades para se trabalhar os dados e gerar
informações como diferencial competitivo.

TEORIA EM PRÁTICA
As redes de computadores são encontradas na maioria
das empresas, podendo ter uma abrangência de pequeno
escritório até redes com muitos dispositivos e serviços
disponibilizados por meio de aplicações aos colaboradores.
São equipamentos como: computadores, impressoras,
câmeras, servidores, roteadores, access point,etc., que
podem compor toda essa estrutura.
Entre as diversas possibilidades de serviços que podem ser
configurados em um servidor estão os bancos de dados.
Peças importantes para que se possa ter uma forma
segura de armazenar os dados e possibilitar a geração de
informações úteis a cada segmento.

87
Acerca das aplicações indicadas na implementação dos
bancos de dados orientados a documentos, se caso uma
empresa tiver dois bancos de dados:
• O primeiro, um servidor local que recebe conexões de
colaboradores para acessar os serviços disponíveis a fim
de se desempenhar as tarefas pertinentes à função de
cada colaborador.
• O segundo é um servidor web com o e-commerce
da empresa. Esse servidor recebe muitas visitas
diariamente, e as compras são gerenciadas pelo sistema
de gerenciamento de banco de dados.
Suponha que a empresa necessite de informações sobre
os tipos de problemas que os clientes têm no e-commerce e
quais atividades estão sendo realizadas pelos colaboradores
da empresa, a fim de se verificar a tratativa dos problemas.
Utilizando um banco de dados orientado a documentos,
qual a indicação para o processamento dessas informações
em servidores geograficamente separados?

VERIFICAÇÃO DE LEITURA

1. Como forma de organizar e possibilitar a identificação de


um objeto inserido no banco de dados, são utilizadas as
chaves. Um exemplo de uma dessas aplicações pode ser
observado no script a seguir:

“id”:”1”,

88
“atletas”: {

“nome”: “Felipe”,

“sobrenome”: “Melo”,

},

“características”: [“volante”, “destro”, “velocidade”,


“força excessiva”]

Assinale a alternativa que descreve o nome utilizado


para a chave identificadora nos bancos de dados
orientados a documentos.
a. Chave primária.
b. Chave Estrangeira.
c. Identificador de Chave.
d. Identificados unívoco.
e. Identificador Único Universal.

2. Uma concessionária de rodovia analisou os veículos que


passaram por uma praça de pedágio qualquer. Após um
tempo, foram apresentados os seguintes dados:

Caminhão, moto, caminhão, veículo, veículo, veículo,


veículo, moto, caminhão, veículo, veículo, moto,
caminhão, caminhão, veículo, moto, veículo, caminhão,
veículo, veículo, moto.

Um banco de dados orientado a documentos que


utilize o mecanismo de MapReduce para selecionar as
infomações, fará os processos de:

89
a. Entrada de informações >> Divisão >> Separação >>
Eliminação >> Redução >> Saída.
b. Captura de dados >> Separação >> Divisão >> Junção
>> Eliminação >> Saída.
c. Entrada de dados >> Divisão >> Mapeamento >>
Junção >> Redução >> Saída.
d. Captura de informações >> Eliminação >>
Mapeamento >> Junção >> Redução >> Saída.
e. Entrada de dados >> Separação >> Mapeamento >>
Divisão >> Redução >> Saída.

3. O CouchDB é uma solução quando se tem a necessidade


de um servidor de banco de dados orientado a
documentos. Quanto às suas características, observe as
afirmativas a seguir:

I. O CouchDB possibilita apenas ser estruturado


em cluster.

II. O CouchDB utiliza o mecanismo de MapReduce para


agilizar a inserção de dados.

III. O CouchDB pode ser acessado remotamente, tanto em


rede local quanto em rede externa, por meio de um
IP público.

Assinale a alternativa correta.

a. Somente a afirmativa I está correta.


b. Somente a afirmativa II está correta.
c. Somente a afirmativa III está correta.
d. Somente as afirmativas I e II estão corretas.
e. Somente as afirmativas II e III estão corretas.

90
Referências
ANDERSON, J.; SLATER N. CouchDB: the definitive guide. Massachusetts: O’Really
Media, 2010.
BLUESOFT Labs. CouchDB Database, William Miranda, Papo Reto. YouTube, 22 mar.
2016. Disponível em: <https://www.youtube.com/watch?v=3tz3FSz_jAw>. Acesso em:
11 ago. 2019.
CouchDB. Disponível em: <http://couchdb.apache.org/>. Acesso em: 11 ago. 2019.
MENEGHETTI, D. Como funciona um download por torrent? Publicado em 24
maio 2013. Disponível em: <https://super.abril.com.br/mundo-estranho/como-
funciona-um-download-por-torrent/>. Acesso em: 28 ago. 2019.
RAMARKRISHNAN, Raghu. Sistemas de gerenciamento de banco de dados. Porto
Alegre: AMGH, 2011.
TecMundo. TecMundo explica: como funciona um download via torrent? YouTube,
14 out. 2013. Disponível em: <https://www.youtube.com/watch?v=HJhzdADYXXo>.
Acesso em: 11 ago. 2019.

Gabarito

Questão 1 – Resposta: E.

Resolução: a chave identificadora utilizada nos bancos de dados


orientados a documentos são conhecidas pelas siglas UUID
(Identificador Universal Único). Na figura, essa chave foi chamada
de “Id” na linha 27 do arquivo escrito em JSON.

Questão 2 – Resposta: C.

Resolução: o MapReduce é uma técnica utilizada nos bancos de


dados orientados a documentos que visa buscar, em uma massa
de dados, informações conforme o filtro desenvolvido, por meio de
mapeamento e redução dos dados. Para isso, os seguintes passos
são seguidos: Entrada de dados >> Divisão >> Mapeamento >>
Junção >> Redução >> Saída.

91
Questão 3 – Resposta: C.

Resolução: a afirmativa I está incorreta, pois o CouchDB pode


ser configurado como servidor único ou em cluster. A afirmativa II
está incorreta, pois o mecanismo de MapReduce é utilizado para
agilizar a consulta dos dados, e não a inserção. A afirmativa III está
correta, pois, nas primeiras configurações, é possível determinar os
endereços remotos e se esse tipo de acesso será permitido.

92
Modelo orientado a chave/valor
Autor: Marcio dos Santos

Objetivos

• Compreender as diferenças entre bancos relacionais


e não relacionais.

• Compreender os conceitos de chave/valor em


bancos não relacionais.

• Diferenciar as estruturas de armazenamento


entre bancos relacionais em detrimento aos não
relacionais.
1. Introdução

Como já abordado anteriormente, bancos de dados não relacionais


possuem características interessantes quando comparados aos mais
comumente usados bancos relacionais. Em um primeiro momento,
principalmente se você já estiver habituado à linguagem SQL, a
estrutura NoSQL pode ter lhe causado uma quebra de paradigmas
e estranheza, mas acreditamos que no decorrer das unidades de
aprendizado você já tenha conseguido se habituar a este novo
paradigma.

Nesta unidade, guiaremos você pelo aprendizado de maneira


sistemática quanto aos conceitos de armazenamento de dados
baseado em chave-valor e para isso será necessário que você
tenha absorvido com eficácia os conteúdos aplicados nas unidades
anteriores para lograr êxito de agora em diante, principalmente
quanto às formas como os dados são tratados em uma
estrutura NoSQL.

PARA SABER MAIS

Bancos de dados não relacionais (NoSQL) quebram


os paradigmas pregados pelo SQL, que estrutura o
armazenamento de dados em tabelas (entidades) que
se relacionam entre si. Ao manipular dados em NoSQL,
veremos que os mesmos dados são armazenados de
formas bastante diferentes; estas estruturas adotadas por
bancos NoSQL geralmente são empregadas em projetos de
médio e grande porte.

94
2. SQL x NoSQL

Para facilitar a assimilação dos conceitos que serão utilizados no


decorrer desta unidade, faremos uma separação das características de
cada estrutura de bancos de dados, conforme resumido no Quadro 1. É
importante que você consiga assimilar estas diferenciações, de forma a
compreender com maior eficácia os princípios de chave/valor que serão
tratados mais adiante.

Quadro 1 – Diferenças entre SQL e NoSQL

SQL NoSQL

Schema baseado em tabelas com A definição dos tipos de dados ocorre em


definição de tipos de dados tempo de execução (conceito on the fly)

Tem normalização de tabelas (Formas Não há especificação para este critério


Normais) com foco na eliminação de
redundância e economia de espaço

Utilização de Junção (Joins) de dados Não possui junção de dados,


considerando que não há tabelas
para se relacionarem entre si –
embora possam existir referências
entre coleções, por exemplo

Possui maior nível de segurança, mas Possui menor segurança,


ocasiona mais lentidão em execução porém é mais rápido

Tem como uma de suas características Possui evolução horizontal, permitindo a


a evolução vertical, que requer criação de ambientes de armazenamento
maior estrutura de hardware de baseados em cluster, particionando os
acordo com a demanda de dados dados em vários servidores distintos

Sistemas que utilizam bancos É mais versátil e tem maior


relacionais geralmente possuem adaptação a mudanças. É mais
estruturas orientadas a dados, ou customizável e dinâmico para
seja, focam seu escopo nos dados que sistemas propensos a mudanças.
podem ser recebidos, o que os torna
menos adaptáveis a mudanças.

Fonte: elaborado pelo autor.

95
ASSIMILE
Clusterizar, em uma tradução literal, significa aglomerar.
Na computação, o termo se aplica às estruturas em que
dois ou mais computadores (geralmente servidores) se
unem para executarem uma tarefa, trabalhando como
se fossem apenas uma máquina. Tal procedimento é
bastante utilizado na manipulação de dados ou softwares
que requerem grande poder de armazenagem ou
processamento.

A abordagem de um banco de dados baseado em chave/valor é um dos


modelos mais simples que podem existir para se manipular dados de
maneira estruturada, com baixo consumo de memória para armazenar e
baixo custo de processamento em consultas.

O próprio nome da estrutura já aponta o seu funcionamento. Todo dado


armazenado está diretamente ligado a uma chave e, consequentemente,
cada chave possui seu respectivo valor que pode ser de qualquer tipo:
string, inteiro, booleano, imagens, objetos Json, etc.

Estas chaves são únicas na extensão do banco de dados inteiro.


Fazendo-se uma alusão aos bancos de dados relacionais, essas chaves
funcionariam como um campo autoincremento, que não permite
duplicação de valores em uma mesma tabela. Mas como bancos NoSQL
não trabalham baseados em schemas de tabelas, esta restrição se
estende ao banco inteiro. De acordo com Claudino (2015, p. 39):

O Modelo Chave-valor também não agrupa os dados por instâncias,


diferentemente do realizado no Modelo Relacional por meio de tabelas.
No modelo Chave-valor todos os dados estão armazenados em uma
estrutura composta apenas por duas colunas. Essa característica
impossibilita a definição de esquemas de dados, sendo possível a

96
introdução de algum metadado apenas por meio da nomenclatura
explícita das chaves. Também não existe a possibilidade de realização de
consultas mais complexas, como subconsultas. É possível realizar apenas
uma consulta por vez e, baseando-se em seu resultado, realizar uma
segunda. Essa perspectiva torna esse modelo de dados mais simples,
o que diminui os tempos de resposta, permitindo que a capacidade
de armazenamento de suas bases de dados seja uma das maiores dos
sistemas enquadrados na categoria NoSQL. (CLAUDINO et al., 2011, p. 39)

Com este escopo (o que também se aplica a outros modelos de


banco NoSQL), é necessário que esteja atrelado a uma forte camada de
consistência de dados que deve ser feita na aplicação que manipulará o
banco – considerando que nativamente, devido à sua filosofia, bancos
de dados não relacionais não garantem a consistência dos dados que
manipulam/gerenciam (TOTH, 2011, p. 2). Embora esta premissa possa
soar um pouco estranha àqueles que são mais acostumados com
bancos de dados relacionais, ela faz todo o sentido, considerando que
a função do banco é armazenar dados e não propriamente gerenciar
regras de negócio – papel este que compete à aplicação (Java, PHP,
Python, C#, etc).

Uma máxima que existe na computação e predomina em bancos


NoSQL: quanto maior a velocidade de uma aplicação, menor a sua
complexidade; quanto mais lenta, mais complexa ela se torna. Desta
forma, estas brechas permitidas por bancos NoSQL são os fatores que
os tornam tão rápidos, em detrimento a bancos relacionais que, por
serem mais rígidos em suas estruturas, são mais lentos.

Assim como citado anteriormente – embora não seja uma regra -,


bancos NoSQL têm mais aceitabilidade em ambientes que demandam
maior fluxo de dados dinâmicos, como um e-commerce, por exemplo.
Sua aplicabilidade também é bem vista em sistemas de grande porte e
de alto fluxo, como em plataformas de redes sociais (Facebook, Twitter,
Instagram). Em contraponto encontram-se a redundância e replicação
de dados, como evidenciado por Toth (2011, p. 3):

97
Embora as vantagens de velocidade no armazenamento e recuperação
de dados sejam indiscutíveis, é necessário considerar a quantidade de
dados que esse modelo gera, uma vez que existe muita redundância e
replicação de dados.

Um exemplo real pode se basear em um problema para armazenar


as lojas de um shopping Center divididos em diversos tipos de
departamentos, teremos muitos dados replicados para cada registro.
Por exemplo, para cada registro de uma loja no shopping é necessário
replicar o atributo departamento, sendo que em um modelo relacional
podemos trabalhar com identificadores e aplicar conceitos normalização
no esquema evitando que se repliquem os dados descritivos de uma
entidade desnecessariamente. (TOTH, 2011, p. 3)

3. Conhecendo o Redis
~

Utilizaremos o Redis como base explicativa desta unidade. O Redis, de


acordo com o próprio site da ferramenta, é uma estrutura de dados que
possui suporte a diversos tipos de dados como Strings, listas, conjuntos,
hashs, bitmaps e outros. Por sua simplicidade, é a estrutura mais
utilizada no mundo para armazenamento baseado em NoSQL. Já nas
palavras da Amazon,

O Redis é um armazenamento de estrutura de dados de chave-valor


de código aberto e na memória. O Redis oferece um conjunto de
estruturas versáteis de dados na memória que permite a fácil criação
de várias aplicações personalizadas. Os principais casos de uso do Redis
incluem cache, gerenciamento de sessões, PUB/SUB e classificações.
É o armazenamento de chave-valor mais conhecido atualmente. Ele
tem a licença BSD, é escrito em código C otimizado e é compatível com
várias linguagens de desenvolvimento. Redis é um acrônimo de REmote
DIctionary Server (servidor de dicionário remoto). (AMAZON, 2019)

98
Desta forma, é possível afirmar que bancos não relacionais
baseados em chave-valor possuem tipos de dados simples (ou,
fracamente tipados).

Sua estrutura traz os dados para a memória do servidor para que


sejam consumidos por uma aplicação e, por este motivo, dependendo
da estrutura dos dados requisitados, o seu uso pode não ser muito
recomendado – lembrando que esta é apenas uma exceção.

O Redis, assim como os demais modelos baseados em chave-valor, são


de fácil implantação e, o resgate de valores através das chaves às quais
seus registros estão associados, é relativamente rápido, mas agrega
como desvantagem a recuperação de dados através de consultas mais
complexas (Lóscio et al., 2011, p. 6).

3.1 Instalando o Redis (Windows)

Utilizaremos, por padrão, a estrutura do Redis em ambiente Windows e


sua execução se dará através do prompt de comando (MS-DOS).

O download pode ser realizado diretamente pelo site oficial no


formato tar.gz ou pelo Github da Microsoft (faça uma pesquisa no
Google pelo tema; um dos primeiros resultados retornará este
destino) no formato MSI – facilitando a instalação. Adicionalmente,
caso tenha optado pela versão que está disponível no Github,
você necessitará baixar também o arquivo .zip disponível na
mesma página.

Finalizada a instalação, descompacte o .zip e execute o arquivo


redis-cli.exe. Ao executá-lo, você estará em ambiente de
criação/manipulação do banco de dados NoSQL utilizando a
estrutura do Redis.

99
3.2 Utilizando os recursos de chave/valor

O uso dos recursos de chave/valor são, como já informados,


extremamente simples conforme apontado na Figura 1.

Figura 1 – Modelo de Chave/valor em NoSQL

CHAVE VALOR

usuario José

usuario2 Pedro

idade 38

casado true

Fonte: elaborada pelo autor.

Uma característica que deve ser levada em consideração é quanto à


tipagem de dados. Observe que, no exemplo acima, não há uma menção
dos tipos de dados envolvidos para cada entrada; existe somente a chave
e seu respectivo valor.

A dispensa explícita de tipos de dados torna o manuseio da


estrutura muito mais dinâmica – característica inerente às estruturas
baseadas em NoSQL.

Mas cuidado, isso não significa que os tipos de dados não são levados
em consideração. Como ocorre um processamento em tempo de
execução de cada entrada realizada, os dados são previamente
reconhecidos pela linguagem e interpretados conforme seus
respectivos tipos, ou seja, se um número for setado na estrutura, ele
será lido e considerado como um dado numérico e aceitará operações
de incremento ou decremento, por exemplo. Já uma string, ao ser
reconhecida como tal categoria de dados, será tratada como tal, como
nos aponta Toth (2011):

100
O modelo apresenta a proposta que permite que o desenvolvedor efetue
a persistência de dados totalmente livre de definições de estrutura para
esquema. Como o nome já diz e sugere, trata-se de uma abordagem
parecida com uma tabela hash. A informação do conteúdo é armazenada
e um índice em forma de um tipo primitivo de dado é usado para mapeá-
lo. O conteúdo pode ser armazenado em qualquer formato, seja uma
string, inteiro, matriz, ou objeto. Pelo fato de ter uma chave de indexação
para mapear um valor, a inserção e a recuperação se torna mais fácil e
com interface simplificada. (TOTH, 2011, p. 3)

3.3 Executando comandos de chave/valor no Redis

Após ter instalado o Redis, execute o arquivo redis-cli.exe. O prompt


de comando será aberto e você poderá executar os comandos para
interagir com a base de dados.

No exemplo disposto na Figura 2, a seguir, foi utilizado o comando SET


para setar o valor José à chave usuário:

Figura 2 – Utilizando comando SET e GET


~

1-'·
{J'\
-....J

-....J

V)
\.O

___.
1--l

1--l

Ili
m
w

(/)

o(/)
ro
©
©

o
Nu NA N

e
e
V

u
)
o

1-'·
{J'\
-....J

-....J
\.O

___.
1--l

1--l

G)

Ili
m
w

(/)
©
©

o
e
e
V

)
=

=
o(/)
m ro

-....J
1--l

1--l
{J'\
-....J

\.O
w
©

Fonte: elaborada pelo autor.

O mesmo exemplo de estrutura se aplica a dados numéricos,


conforme Figura 3:

101
Figura 3 – Utilizando comando SET e GET com dados numéricos

127.0.0.1:6379> SET idade 48


OK
127.0.0.1:6379> GET idade
48
li li

127.0.0.1:6379>

Fonte: elaborada pelo autor.

Tratando-se de dados numéricos, o Redis permite a utilização de


determinados comandos como o INCR para incrementar e o DECR para
decrementar. É possível, ainda, realizar a alteração de valores vinculados
a uma chave. Para isso, basta apontar um novo valor a uma chave
previamente criada, conforme demonstra a Figura 4. Adicionalmente,
uma chave também pode ser excluída, utilizando, para isso, o
comando DEL.

Figura 4–Utilização de comandos no Redis

127.0.0.1:6379> GET idade


"48"
127.0.0.1:6379> SET idade 55
OK
127.0.0.1:6379> GET idade
"55"
127.0.0.1:6379> DEL idade
(integer) 1
127.0.0.1:6379> GET idade
(nil)
127.0.0.1:6379>

Fonte: elaborada pelo autor.

102
Os dados também podem ser armazenados em lote, ou seja, em uma
sequência, sem a necessidade de se armazenar um registro de cada vez.
Para isso, basta inserir uma cadeia de chaves e seus respectivos valores
conforme demonstrado na Figura 5.

Figura 5–Utilização do MGET e MSET

127.0.0 . 1:6379> MSET nome Jose sobrenome Antonio idade 48 sexo ~, casado true
OK
127.0.0.1:6379> MGET nome sobrenome idade sexo casado
1 ) "Jose"
2 ) "Antonio"
3 ) "48"
4 ) "M"
5 ) "true"
127.0.0.1:6379>

Fonte: elaborada pelo autor.

4. Conclusão

O uso de uma estrutura baseada em Chave/Valor tem muitas vantagens


quando se procura atingir um melhor desempenho em bancos de
dados NoSQL. Porém, deve-se atentar à sua real necessidade, pois,
como pudemos ver no decorrer da unidade, a estrutura é relativamente
simples e pode não atender com eficácia a cenários com certa
complexidade de dados.

De contrapartida, pudemos também observar a simplicidade como


ferramentas como o Redis manipulam os dados, seja em sua inserção ou
em sua recuperação de dados através de consultas simples. Em resumo,
cabe ao desenvolvedor analisar com destreza o cenário da aplicação e
optar por este tipo de modelo.

103
Outros bancos de dados que atendam à estrutura chave-valor também
podem ser explorados para fins de estudo e ampliação de possibilidades
de uso, assim, deixamos como recomendação a exploração de
ferramentas como Riak e GenieDB, ótimos bancos de dados no padrão
key-value.

TEORIA EM PRÁTICA
Suponha que você fosse um DBA (data base administrator)
e precisou utilizar uma estrutura NoSQL para armazenar
os dados de uma rede social. Devido à sua facilidade
no manuseio, você utilizou o Redis como plataforma de
gerenciamento e usou o Modelo Chave/Valor em sua forma
padrão de instalação.
Sabe-se que para armazenar os dados desta rede social
você precisará de alguns campos como nome, email, senha,
nome de usuário, telefone, cpf e data de nascimento, sexo,
estado civil. Outros dados podem ser inseridos neste mesmo
escopo para tornar sua aplicação mais rica em recursos e
elementos de consulta, embora não sejam obrigatórios.
Após concluir o armazenamento de pelo menos 3 usuários,
liste todos os dados na tela em forma sequencial. Feita
esta listagem, efetue alterações básicas nos registros
(modificando um e-mail, por exemplo) para colocar em
prática os recursos de manipulação de dados.
Finalizado o passo anterior, escolha um dos usuários
inseridos e exclua-o do banco de dados e em seguida liste
novamente os dados para averiguar se de fato o usuário
foi removido.
Uma dica é recorrer à documentação do Redis para ter
acesso a todas as sintaxes disponíveis.

104
VERIFICAÇÃO DE LEITURA

1. O modelo de banco de dados NoSQL baseado em Chave/


Valor é considerado um dos mais simples e objetivos
para se trabalhar, principalmente por sua sintaxe
descomplicada e intuitiva. Esta simplicidade de estrutura
está também atrelada aos tipos de dados que ele aceita,
ou seja, ele é considerado um banco de dados:

a. Fortemente tipado.
b. Fracamente estruturado.
c. On the fly (em tempo de execução).
d. Relacional.
e. Fortemente estruturado.

2. Em bancos de dados baseados em chave-valor, as sintaxes


para manipulação dos dados (seja inserção, alteração ou
recuperação) possuem baixa complexidade. Uma prática
comum durante a manipulação é trabalhar com cadeia
de registros ao invés de utilizar a manipulação individual.
Bons exemplos desta estrutura de manipulação são os
comandos MSET e GET, que, respectivamente,

a. Inserem uma chave ao valor; resgatam os valores de


um registro.
b. Inserem dados do tipo inteiro; inserem dados do
tipo String.
c. Resgatam valores em massa; inserem
valores em massa.
d. Inserem valores em massa; resgatam um
valor isolado.
e. e) Inserem valores isolados; resgatam dados do
tipo inteiro.

105
3. Bancos de dados relacionais popularizaram-se na
década de 1970, mas com a expansão da informação
e a necessidade de rápidas respostas a consultas
surgiram os bancos de dados não relacionais, com
uma abordagem diferenciada quanto às estruturas
de armazenamento e recuperação das informações.
As diferenças entre ambos os bancos são bastante
evidentes, mas pode-se dizer que a mais importante
no NoSQL é:

a. A capacidade de definir tipos de dados em suas


estruturas.
b. O fato de possuir chaves primárias para cada inserção.
c. O fato de não possuir schemas pré-definidos.
d. Poder realizar relacionamento entre dados
através de Joins.
e. O fato de serem mais lentos que bancos relacionais.

Referências
AMAZON, 2019. O que é o Redis? Disponível em: <https://aws.amazon.com/pt/
elasticache/what-is-redis/>. Acesso em: 02 set. 2019.
CLAUDINO, Myller; SOUZA, Damires; SALGADO, Ana Carolina. Mapeamentos
conceituais entre os modelos Relacional e NoSQL: uma abordagem comparativa.
Revista Principia, (28), p. 37-50, 2015.
LÓSCIO, Bernadette Farias; OLIVEIRA, H. R. de; PONTES, J. C. de S. NoSQL no
desenvolvimento de aplicações Web colaborativas. VIII Simpósio Brasileiro de
Sistemas Colaborativos, v. 10, n. 1, p. 11, 2011.
TOTH, Renato Molina. Abordagem NoSQL – uma real alternativa. [S.l.]:
Universidade Federal de São Carlos – Campus Sorocaba, 2011. Disponível em:
<https://dcomp.sor.ufscar.br/verdi/topicosCloud/nosql_artigo.pdf>. Acesso em: 23
jul. 2019.

106
li►. Gabarito

Questão 1 – Resposta: C.
Resolução: como os dados são criados e resgatados de forma
dinâmica, em tempo de execução, eles recebem esta nomenclatura:
on the fly.
Questão 2 – Resposta: D.
Resolução: o MSET é utilizado para inserir uma cadeia de valores,
enquanto o GET resgata apenas um valor cadastrado.
Questão 3 – Resposta: C.
Resolução: a velocidade de execução é uma das características
de bancos NoSQL e isso é alcançado através de várias diferenças
entre sua arquitetura e a arquitetura de bancos relacionais; uma
das características mais marcantes é justamente o schema less (não
possui schemas).

107
Modelo orientado a família de
colunas
Autor: Marcio dos Santos

Objetivos

• Identificar as características de bancos de dados


orientados a família de colunas.

• Compreender a estrutura de um modelo de danco


de dados orientado a família de colunas.

• Compreender a diferença entre o modelo baseado


em família de colunas e os demais modelos NoSQL.

• Conhecer as vantagens e desvantagens em adotar


este modelo de estrutura de banco de dados NoSQL.
1. Introdução
~

Embora não seja pré-requisito, o conhecimento de uma estrutura


de banco de dados relacional seria o caminho mais prático para se
criar uma ponte de conhecimentos e explicitar as características de
bancos NoSQL.

Nesta unidade, veremos mais um modelo de banco de dados não


relacional, conhecido como Modelo Orientado a Família de Colunas
ou Banco de Dados Colunar. Entenderemos as suas características,
bem como a sua aplicabilidade e estrutura básica. Veremos ainda a
linguagem CQL (Common Query Language), utilizada para interagir com
um dos bancos de dados não relacionais mais conhecidos do mercado: o
Cassandra.

A principal ideia desta unidade é conseguir transmitir a ideia de


armazenamento escalonável de quantidades massivas de dados através
de estruturas simples, porém robustas que este tipo de banco é capaz
de proporcionar.

Vamos lá?

PARA SABER MAIS


Na computação, o termo persistência de dados refere-se
ao armazenamento não volátil da informação, ou seja, a
informação é armazenada (em sua íntegra ou fragmentada
em dados) de maneira permanente. Esta característica,
principalmente em Bancos Relacionais, está explicitada
na sigla ACID (Atomicidade, Consistência, Isolamento,
Durabilidade), em que a letra D representa a durabilidade
da informação dentro de uma estrutura de Banco de Dados.

109
2. Características do modelo colunar: vantagens e
desvantagens

Um modelo colunar trabalha com persistência de dados – diferente do


modelo orientado a chave-valor, por exemplo, cuja estrutura é capaz
de persistir dados de forma durável e temporário. Esta persistência é
atrelada à rápida resposta do banco, pois sua estrutura é otimizada
para uma rápida recuperação de colunas com baixa latência, sendo,
inclusive, utilizado em plataformas de grande porte como o Google Earth
(OLIVEIRA, 2017).

Independente da estrutura que esteja sendo utilizada para persistir


dados em um banco, atente-se à característica comum: a velocidade
de consulta aos dados será sempre um dos objetivos esperados,
principalmente quando se trabalha com um grande volume de dados
como nos aponta Oliveira (2017):

Esta classificação é dada devido ao tamanho e complexidade da


informação a ser armazenada, e não somente ao tipo de SGBD utilizado.
A Big Data preocupa- se com a quantidade de dados (volume, variedade
e velocidade) para o processamento dos mesmos, e concebe-se como o
principal desafio a vencer, saber o que guardar e fazê-lo de modo cada
vez mais rápido. Big Data é um termo amplamente usado para referir um
conjunto de dados muito grande ou complexo num sistema de bases de
dados. (OLIVEIRA, 2017, p. 27)

Obviamente, as características de segurança, não redundância,


consistência e flexibilidade do banco também devem ser levadas em
consideração. Mas, em aplicações críticas que lidam com alta demanda
de requisições de usuários, o fator velocidade de resposta a consultas
deve sempre encabeçar a lista de requisitos a serem atingidos.

Este objetivo magno é o que faz grandes corporações como Facebook e


Netflix, por exemplo, serem adotantes de modelos não relacionais para

110
armazenamento, dada a grande quantidade de requisições simultâneas
realizadas por seus usuários em fracões de segundos.

Armazenamentos no formato linear (comuns em bancos relacionais)


atrela os registros de dados a uma linha dentro de uma tabela, podendo
cruzar informações armazenadas em outras tabelas através de JOINS,
caracaterizando os relacionamentos. Já o armazenamento colunar,
que é amplamente utilizado em aplicativos analíticos, organiza o
armazenamento em colunas independentes e os relacionamentos não
existem. Vejamos um exemplo abstrato e comparativo entre a Figura 1 e
a Figura 2:

Tabela 1 – Exemplo de uma tabela em banco relacional


id nome email
20 José Miguel josemiguel@dominio.com
21 Antônio dos Santos andoniodossantos@dominio.com
22 Pedro Lucas pedrolucas@dominio.com
Fonte: elaborada pelo autor.

Figura 1 – Exemplo de um Modelo Orientado a Família de Colunas

ID NOME
id nome
id valor id valor
1 20 1 José M iguel
2 21 2 Antônio dos Santos
3 22 3 Pedro Lucas

EMAIL
- email
-

id valor
1 josemiguel@dom in ia.com
1 2 antoniodossantos@dominio.com
3 pedro lucas@dominio.com

Fonte: elaborada pelo autor.

111
Ainda que na Figura 2 a estrutura aparente conter 3 tabelas com 3
linhas cada uma, esta exemplificação foi apenas para que você pudesse
compreender a estrutura de maneira mais objetiva.

Em uma consulta SQL convencional, buscar-se-ia as informações


constantes na tabela e uma tupla seria construída com base nos
requisitos da busca. Por exemplo:

SELECT MAX(id) FROM cadastro;

Os passos executados nesta consulta seriam os seguintes:

1. O banco de dados receberia a consulta.


2. Em seguida, o banco varreria a tabela inteira.
3. A seguir, uma tupla seria construída para armazenar um resultado
(valor máximo do campo ID, no caso).
4. Por fim, o valor máximo seria armazenado na tupla.

Com a estrutura do NoSQL (Figura 2), a consulta seria feita diretamente


na coluna ID, desconsiderando as demais colunas que não fazem parte
dos requisitos buscados (nome e email).

Ao excluir as etapas de criação de uma tupla para exibir resultados


e varrer uma tabela inteira (linhas e colunas) em busca de valores
específicos que atendam à busca realizada, obtém-se um ganho de
processamento, ou seja, diminui-se o tempo de consulta.

Este modelo (bastante similar ao modelo chave/valor, ao menos neste


critério) possui três elementos: chave (identificador único), valor (String,
numérico, booleano, etc) e timestamp (o valor armazenado).

Uma família de colunas seria o agrupamento de várias colunas


para formar o resultado de uma consulta especificamente, sendo
possível adicionar a uma consulta quantas colunas forem desejadas,
dependendo do resultado esperado.

112
ASSIMILE
Uma característica comum a qualquer banco de dados
NoSQL é seu desvinculamento das normalizações
amplamente empregadas em Bancos Relacionais (1FN,
2FN, 3FN 4FN, 5FN). Isso significa que, em determinados
momentos, podem ocorrer redundâncias de dados. Embora
a redundância não seja vista como algo viável a um sistema
de banco de dados, a inconsistência de dados acaba por ser
adotada visando um melhor desempenho nas consultas.
Como este modelo não suporta junções de tabelas (Joins), a
desnormalização é uma consequência (OLIVEIRA, 2017).

3. Supercolunas

Se você está familiarizado com programação de computadores, você


deverá se lembrar do tipo de dados denominado vetor. Adicionalmente,
você também deve se lembrar das matrizes, que nada mais são que
vetores de vetores. O mesmo conceito se aplica às supercolunas: são
colunas que em sua estrutura possuem outras colunas. Esta estrutura
permite que uma gama de dados seja armazenada dentro de uma mesma
coluna, otimizando os resultados de busca como nos aponta a Figura 2.

Figura 2 – Exemplo de coluna com subcolunas


Família de Col unas TI

Nome Coluna l Valor Col una l 1Timestamp Coluna l


Su per Coluna A Nome Coluna 2 Va lor Coluna 2 1 Timestamp Col una 2
Nom e Coluna 3 Val or Cal una 3 1 Timest amp Coluna 3

Li nha l

Nome Coluna 4 1 Valor Coluna 4 1Tímestamp Coluna 4


Super Col una B Nome Coluna 5 1 Valor Coluna 5 1Timestamp Coluna 5
Nome Coluna 6 1 Va lor Coluna 6 1 Timestamp Col una 6

Fonte: Oliveira, 2017.

113
Quando temos uma coleção de supercolunas, ou seja, várias colunas
com supercolunas, temos uma estrutura chamada de superfamília de
colunas. Este tipo de estrutura é comumente utilizado, pois é a maneira
mais versátil de se trabalhar com dados de maneira escalável em
bancos NoSQL.

3.1 Keyspace

Fazendo uma ligação com o modelo relacional, o keyspace funciona


como um dicionário de dados, que aponta para todas as colunas,
famílias de colunas, supercolunas e superfamília de colunas e suas
respectivas ligações entre si. Desta forma, uma consulta completa
exibiria o resultado de uma superfamília de colunas, como demonstra
a Figura 3.

Figura 3–Exemplo de superfamília de colunas


ID NOME
id
~

nome
-
id valor id valor
1 20 1 José Miguel
2 21 2. Antônio dos Santos
3 22 3 Pedro Lucas

CHAVE VLOR

ID NOME

id nome

1 id valor id vator
1 20 1 José M iguel
2 21 2 Antônio dos Santos
3 22 3 Pedro lucas

Fonte: elaborada pelo autor.

Perceba que o exemplo apresentado na Figura 3 pode ser expandido


ainda mais, ou seja, é possível que a última coluna gerada seja inserida
em uma outra coluna, aumentando o nível da família.

114
A manipulação de dados utilizando a família de colunas também é
algo que deve receber uma atenção especial, pois, em um processo
de inserção, por exemplo, é necessário apenas adicionar-se uma
nova coluna à família (uma coluna dentro de outra coluna, criando
uma supercoluna) e ela já fará parte da estrutura de um determinado
registro; o mesmo conceito se aplica à edição de dados, que,
diferentemente de uma estruturra relacional, não precisa carregar
uma tupla virtual para realizar a edição: apenas invoca-se a coluna que
contém o dado a ser editado.

Esta estrutura demonstra o quão escalável é este tipo de banco de


dados e o quão adaptável aos diferentes cenários ele pode ser para
grandes massas de dados (não é recomendado para pequenos volumes
de informação).

De contrapartida, quanto mais complexa for a estrutura de suas colunas,


maior será a complexidade de manipulação (inserção, edição, exclusão
ou mesmo consulta). Isso ocorre porque será necessário adentrar vários
níveis de colunas para se chegar ao dado que se pretende manipular, e
isso, no nível da estrutura do código, pode ser algo complexo.

4. Conhecendo o Cassandra

O Cassandra, desenvolvido pelo Facebook, tornou-se um projeto


Open-source em 2009 e passou a ser mantido pela Apache Fundation.
Ele baseia sua estrutura de distribuição no Dynamo (da gigante
Amazon) e organiza seus dados com base no BigTable (do também
gigante, Google).

A estrutura do Cassandra foi pensada para trabalhar, por padrão, de


maneira distribuída, ou seja, escalável de forma horizontal – como prega
o padrão NoSQL. Para pequenas demandas, a estrutura do Cassandra
seria subutilizada.

115
Outra característica interessante do Cassandra é a sua arquitetura
desenvolvida para trabalhar de forma descentralizada, de forma que
cada nó que compreende a estrutura do banco possui as mesmas
funções, facilitando todo o processo de manutenção e até mesmo
expansão. A não existência de JOINS e ações em tempo de execução
também são pontos fortes, conforme destacado por FERREIRA et
al. (2014):

O Cassandra é um SGBD de natureza distribuída que utiliza o modelo


de registros particionados com consistência configurável. Esses
registros são armazenados em tabelas chamadas de Column Families.
Nessas tabelas, a primeira parte da chave primária é chamada chave
de partição e serve para definir em qual partição o registro será
armazenado. Dentro de uma partição, os registros são agrupados
pela chave de agrupamento ou clustering keys. Um ponto importante
que deve ser ressaltado é a não existência de chaves estrangeiras
no modelo do Cassandra. Isso permite que tabelas sejam criadas,
removidas ou alteradas em tempo de execução, sem bloqueios para
atualizações ou consultas. Desta forma, não existe o conceito de junção
e sub-consultas. (FERREIRA et al., 2014, p. 189)

Por ser um banco de dados propriamente desenvolvido para atuar de


forma distribuída, o Cassandra já tem, em sua arquitetura, o princípio
de divisão de armazenamento em nós (nodes). Cada nó corresponde a
uma máquina da estrutura e os dados a serem armazenados passam
automaticamente por um processo de particionamento/distribuição
entre os nós disponíveis.

Estas partições são distribuídas entre os nós do cluster, além de serem


replicadas em diferentes nós, provendo a disponibilidade dos dados em
casos de falha. Cada nó armazenará um range de partições baseado
no hash utilizado para particionamento. Esta arquitetura (explicitada na
Figura 4) é denominada Arquitetura em Anel ou Token Ring.

116
Figura 4 – Estrutura de nodes no Banco de Dados Cassandra

Nó I Nó2 Nó 3

rctfe ·1rct5""tt51r• - • ·1
Anel com t• G)! !.8 CD_! t0 0 )
VNode

Nó 4 Nó 5 Nó 6

VNodes ordenados randomicamente

Fonte: DataStax (2014), citado por Aniceto e Renê (2014).

4.1 Linguagem CQL

O banco de dados Cassandra utiliza a linguagem CQL (Common Query


Language), desenvolvida para o próprio banco. Ela abstrai o conceito
de colunas disposto dentro da arquitetura do banco e assemelha-se
bastante à linguagem SQL (Structured Query Language) utilizada pela
maioria dos Bancos de Dados Relacionais.

No Cassandra, assim como em bancos relacionais, para criarmos uma


estrutura de armazenamento, primeiramente criamos um banco de
dados e posteriormente criamos sua família de colunas (OLIVEIRA, 2017).
Podemos observar no código a seguir um exemplo de linguagem CQL
para criação de uma estrutura de cadastro (DATASTAX, 2019).

CREATE TABLE cadastro(


Id INT,
Nome TEXT,
Email TEXT,
PRIMARY KEY(id)
);

117
As inserções de dados com a linguagem CQL são feitas através do
comando INSERT INTO:

INSERT INTO usuarios(id, Nome ,Email)


VALUES(1,”José”, jose@dominio.com);

As consultas também são bastante similares àquelas realizadas com


linguagem SQL, conforme pode ser observado no trecho em CQL
disposto a seguir, apontado na documentação oficial do Cassandra:

SELECT * | select_expression | DISTINCT partition


FROM [keyspace_name.] table_name
[WHERE partition_value
[AND clustering_filters
[AND static_filters]]]
[ORDER BY PK_column_name ASC|DESC]
[LIMIT N]
[ALLOW FILTERING]

Os campos de uma coluna podem ser atômicos (inteiro, real, texto)


ou do tipo map, contendo assim um grupo de colunas agregadas.
Compreenda como map o tipo de campo que aceita receber vários
valores e, que em bancos relacionais, acasionaria a criação de uma
outra tabela referenciada por uma chave estrangeira, a fim de atender à
segunda forma normal (2FN).

Durante a criação de uma coluna que contenha um campo do tipo map é


necessário fazer a devida referenciação dele. Observe o trecho de código
abaixo, que usa a mesma estrutura citada anteriormente, mas agora
com um campo do tipo map:

118
CREATE TABLE cadastro(
Id INT,
Nome TEXT,
Email TEXT,
Telefones map<text, text, text>,
PRIMARY KEY(id)
);

De forma similar, a estrutura de inserção também é modificada para


colunas que contenham esta estrutura:

INSERT INTO usuarios(id, Nome, Email, Telefone)


VALUES(1, “José”, jose@dominio.com,
{‘Residencial’:’789456123’, ‘Celular’:’321654987’};

A atualização de dados é feita através do comando UPTADE, podendo


conter em sua estrutura a cláusula restritiva WHERE, que limitará a
atualização a uma ou mais regras estabelecidas:

UPDATE cadastro
SET Nome = “Pedro”
WHERE id = 1

A exclusão de dados é feita através do comando DELETE, que pode vir ou


não com a cláucula WHERE em sua estrutura, apontando as restrições de
exclusão a serem adotadas:

DELETE FROM cadastro


WHERE id = 1

5. Conclusão

Em projetos que demandem grande velocidade na manipulação dos


dados (seja em consultas, inserção, edição ou exclusão), bancos NoSQL

119
com Modelo baseado em Família de Colunas torna-se amplamente viável
desde que se tenha uma estrutura clusterizada para comportá-lo.

Pudemos observar que existe um contraponto para o ganho de


desempenho e escalabilidade no armazenamento de dados em bancos
não relacionais do tipo Família de Colunas: a redundância de dados.
Embora este seja um ponto negativo a ser observado na adoção desta
estrutura de banco, convém ressaltar que bancos não relacionais
geralmente são voltados a situações específicas, em que a velocidade
de resposta ocupe patamar maior que as questões de espaço de
armazenamento e restrições de normalização.

TEORIA EM PRÁTICA
Analise o seguinte cenário: você é um DBA (Data Base
Administrator) e precisa utilizar uma estrutura NoSQL
para armazenar os dados de uma rede social. Você
necessitaria criar uma estrutura para armazenar os dados
que trafegassem pela rede: nome dos usuários, e-mails,
postagens, fotos e vídeos.
Sabe-se que a estrutura desta rede social cresce de
forma exponencial e não ordenada, ou seja, pode ocorrer
estruturas de armazenamento distintas entre os vários
posts que ela armazena. Você deverá elaborar uma
estrutura capaz de comportar estes dados, armazenando-
os em um banco não relacional baseado em família de
colunas utilizando diagramas para demonstrar a forma
que os dados seriam organizados. Adicionalmente você
deverá criar uma estrutura minimalista, na linguagem CQL,
que represente os diagramas desenvolvidos. Atente-se
à possibilidade de utilizar supercolunas para dados mais
complexos.

120
VERIFICAÇÃO DE LEITURA

1. O banco de dados Cassandra é específico para atuar:

a. De forma controlada.
b. De maneira distribuída e centralizada.
c. De forma distribuída e free on demand.
d. De forma descentralizada e distribuída.
e. De forma local ou distribuída.

2. As superfamílias de colunas são:

a. As colunas mais externas, que armazenam


subcolunas internas.
b. As colunas que possuem mais duas chaves.
c. Colunas com valores definidos como primários.
d. Colunas organizadas por tuplas.
e. Subcolunas dentro de uma estrutura de linhas.

3. Diferentemente de bancos baseados em modelo chave/


valor, os modelos família de colunas:

a. Possuem escalabilidade vertical.


b. Têm mais velocidade de processamento.
c. Prezam pela durabilidade dos dados persistidos.
d. Armazenam os dados em memória.
e. Não necessitam de uma linguagem específica para
manipulação.

Referências
~
~

ANICETO, Rodrigo Cardoso; XAVIER, Renê Freire. Um estudo sobre a utilização do


banco de dados NoSQL Cassandra em dados biológicos. Disponível em: <http://
bdm.unb.br/handle/10483/7927>. Acesso em: 04 ago. 2019.

121
DATASTAX. CQL Commands – SELECT. Disponível em: <https://docs.datastax.com/
en/archived/cql/3.3/cql/cql_reference/cqlSelect.html>. Acesso em: 03 ago. 2019.
FERREIRA JR., Guilherme R.; FILIPE, Carlos; OLIVEIRA, Daniel. Uso de SGBDs NoSQL
na Gerência da Proveniência Distribuída em workflows científicos. Instituto de
Computação – Universidade Federal Fluminense (UFF), 2014. Disponível em: <http://
www.inf.ufpr.br/sbbd-sbsc2014/sbbd/proceedings/artigos/pdfs/9.pdf>. Acesso em:
01 ago. 2019.
OLIVEIRA, Fábio Vieira de. Migração de bases de dados relacionais para
NoSQL–métodos de análise, 2017. Disponível em: <https://repositorio.iscte-iul.pt/
bitstream/10071/15649/1/FabioOliveira_Tese_MEI.pdf>. Acesso em: 24 set. 2019.

Gabarito

Questão 1 – Resposta: D.
Resolução: uma das principais características do banco de
dados Cassandra é trabalhar com vários nós em um ambiente
clusterizado, ou seja, de forma descentralizada e distribuída.
Questão 2 – Resposta: A.
Resolução: as superfamílias são compostas pela união de várias
subcolunas.
Questão 3 – Resposta: C.
Resolução: a persistência de dados de forma durável é o objetivo
dos bancos de dados baseados no modelo Famílias de Colunas,
diferente dos bancos de dados baseados em chave/valor, cujo
registro é armazenado temporariamente em memória.

122
Modelo orientado a grafos
Autor: Marcio dos Santos

Objetivos

• Conhecer as características de bancos de dados não


relacionais orientados a grafos.

• Conhecer o banco de dados Neo4J.

• Manipular sintaxes para interação com o


banco Neo4J.

• Utilizar queries para interação com os dados


armazenados.

• Conhecer a linguagem Cypher para


interação no Neo4J.
1. Introdução

Bancos de dados não relacionais baseados em modelos orientados


a grafos são amplamente utilizados por empresas cujos dados estão
muito interligados entre si, além de serem fáceis de serem interpretados
em seu modo visual, até mesmo por pessoas não técnicas.

O conhecimento prévio sobre teoria dos grafos e a sua estrutura


facilitará a compreensão do assunto. Todavia, este não é um pré-
requisito, considerando que, no decorrer desta unidade, abordaremos
uma base conceitual sobre o assunto.

Assim, prepare-se para embarcar no fascinante mundo dos grafos para


armazenagem de dados de uma forma diferente e bastante funcional!

2. Instalando o Neo4J

Para iniciar os trabalhos com um modelo orientado a grafos,


utilizaremos o Neo4J, um banco de dados projetado para tratar os
relacionamentos entre os dados com níveis equalizados de importância
entre si (NEO4J, 2019). Para instalá-lo, é necessário acessar o site oficial
da plataforma e clicar sobre o link/botão de download (realize uma
busca por Neo4J e um dos primeiros resultados será o site oficial do
Banco de Dados). Após realizar o download do arquivo, partiremos para
a instalação.

Ainda que não seja uma regra, é importante que a instalação ocorra
em diretórios e pastas sem espaços em sua estrutura, ou seja, é
recomendado que a instalação ocorra em diretórios similares a C:\
pasta\. Para nossas aulas, utilizaremos a instalação dentro do disco C:
(Windows), na pasta neo4j, ficando: C:\neo4j. Já para a armazenagem
dos dados, utilizaremos uma subpasta chamada dados: C:\
neo4j\dados\.

124
Após realizar o download do instalador no site oficial do Neo4J, escolha a
pasta (C:\neo4j) como destino de sua instalação, conforme demonstrado
na Figura 1 a seguir, ressaltando que a instalação em diretórios é feita
sem espaços no nome.

Figura 1 – Local de instalação do Banco de Dados Neo4J


Instalação do Neo4j Desktop X
Escolha o Local da Instalação
Escolha a pasta na qual instalar o Neo4j Desktop,

O Neo4j Desktop será instalado na pasta a seguir. Para instalar em uma pasta diferente,
dique em Procurar e selecione outra pasta, Clique em Instalar para iniciar a instalação,

Pasta de Destino

1 C:v,eo4j\ 1 Prorurar., . J

Neo4j Desktop 1,2, 1 - - - - - - - - - - - - - - - - - - - - - - - - - -

< Voltar Instalar r Cancelar7

Fonte: elaborada pelo autor.

Após concluir a instalação, o ambiente gráfico para gerenciamento


do banco de dados será inicializado com a estrutura similar à
interface gráfica do Neo4J, com os recursos disponíveis, conforme
apresentado na Figura 2 (podendo ter modificações de acordo com a
versão baixada).

125
Figura 2 – Interface gráfica
• Neo4j Oesktop - 12.1 o X
f ile Edil Voew Window Help Oeveloper

My Project

(D


Neo4j Browser
3.2.20

8;)
Add Appltcatoon

8;)

Fonte: elaborada pelo autor.

Como overview do ambiente gráfico e para fins didáticos, explicaremos


as funções básicas do Neo4J. Não aprofundaremos muito na estrutura
do software, pois o objetivo é a compreensão do banco de dados em si
e não da aplicação que o gerencia. Você deverá utilizar a Figura 1 como
guia para se situar sobre os menus utilizados.

• My Project: permite que seja criado um novo projeto (ou até


mesmo projetos separados por clientes). Este nome pode
ser editado.
• Neo4J Browser: inicializa o ambiente no qual serão executadas as
queries junto ao banco de dados.
• Add Graph: cria um novo banco, desde que um projeto tenha sido
previamente selecionado.
• Active Database: mostra as bases de dados que estão ativas
no momento.

126
• Ícone da engrenagem: utilize esta seção para manipular
configurações gerais do banco de dados, inclusive o local de
armazenamento de seu banco que, em nosso curso, deverá ser:
C:\neo4j\dados\.

3. Iniciando um banco de dados

Para iniciar um novo banco, clique em Add Graph > Create a Local
Graph. Um nome deverá ser atribuído à sua base de dados. Utilizaremos
o nome “aula” para nosso banco de dados; este banco poderá ser
localizado no seguinte caminho: C:\neo4j\dados\neo4jDatabases. Com
a base devidamente criada, é possível acessar suas configurações
(botão Manage) ou iniciá-la (botão Start) conforme mostrado na tela
exemplificada na Figura 3.

Figura 3 – Iniciando uma base de dados

Manage [> Stan

Fonte: Elaborada pelo autor.

127
Para iniciar nossos primeiros comandos dentro desta estrutura de banco
de dados, devemos clicar sobre o botão Start. O Neo4J só executará uma
base de dados de cada vez, ou seja, mesmo que você tenha outras bases
configuradas na aplicação gráfica, não poderá executá-las de forma
concomitante.

A administração do banco pode ocorrer via browser interno da interface


gráfica ou pelo seu browser web, como o Google Chrome, por exemplo. A
vantagem de executar o banco em um browser web (Figura 4) é o ganho
de velocidade, que pode praticamente dobrar em alguns casos.

Figura 4 - Neo4J no browser web

0.-nu CM.

l~C

S : scr11cr connect X

Connected to Neo4j You are connected a1 user neo4j


N•e.e 10 mcct you.
lo http: f/ localhost:7474

conneebOn a edentia>s are sto.ed ,n Y'JUf web bcowser.

Fonte: elaborada pelo autor.

A linguagem de programação que utilizaremos para este tipo de banco


será a Cypher. Sua estrutura é bastante simples e lembra bastante
outras linguagens – até mesmo o SQL (Structured Query Language). Uma
de suas vantagens é permitir o uso direto de variáveis.

Todas as instruções passadas via Cypher deverão se embasar em


uma estrutura de grafos. Esta estrutura funciona baseada em Vértices
e Arestas.

128
• Vértices (ou nós/nodes): são as estruturas que armazenam um
determinado dado, podendo estar atreladas a outros vértices-
filhos ou serem dependentes de outros vértices superiores.
• Arestas (ou relacionamentos): são as ligações existentes entre
os diversos vértices de um banco de dados como demonstrado
na Figura 5.

Figura 5 – Exemplificação de Vértices e Arestas

Fonte: elaborada pelo autor.

PARA SABER MAIS


É importante ressaltar que bancos orientados a grafos
utilizam exatamente o conceito matemático (teoria dos
grafos). Geralmente a exibição dos dados em bancos de dados
NoSQL que utilizem este modelo ocorrerá por meio de uma
estrutura visual rica em detalhes de ligações, facilitando a sua
compreensão da hierarquia dos elementos envolvidos.

Em uma estrutura orientada a grafos, é necessário que definamos onde


os relacionamentos se iniciam e para qual direção eles apontam. Assim,
o label informado no relacionamento é crucial, conforme apresentado na
Figura 6 (que é uma adaptação da Figura 5, com foco nos dois vértices
em destaque).

129
Figura 6 - Relacionamento e label

Fonte: elaborada pelo autor.

Dentro do Browser web, no console que aparece no topo da página,


digite o seguinte comando: play movie-graph e, em seguida,
pressione o botão executar, posicionado à frente do console. Este
comando irá exibir um trecho de código exemplo para testes de uma
base de dados fictícia. Copie o código cedido e o adicione ao console.
Após adicioná-lo, clique no botão de executar. Uma base de dados no
estilo de grafos deverá ser criada instantaneamente e a tela deverá ficar
com a seguinte aparência (veja Figura 7).

Figura 7 – Base de dados de exemplo

Fonte: elaborada pelo autor.

130
O efeito visual desta estrutura é bastante atrativo e permite que você
manipule a estrutura de maneira interativa e dinâmica. Observe que
um mesmo nó pode se relacionar com vários outros nós. Esta estrutura
representa um relacionamento do tipo n:n em bancos de dados
relacionais.

3.1 Propriedades e Labels

Bancos de dados com modelos orientados a grafos possuem


identificadores específicos denominados propriedades e labels. Esses
identificadores, embora sejam similares, possuem diferentes funções na
estrutura:

• Propriedades: funcionam como as colunas (em uma alusão aos


bancos relacionais).
• Label: funciona como se fosse a tabela (em uma alusão aos bancos
de dados relacionais).

Em seu banco de teste, clique ou passe o mouse sobre o nó Robert


Zameckis. Você poderá observar que uma linha com algumas
informações foram apresentadas:

• Person
• <id>:151
• born: 1951.0
• name: Robert Zemeckis

Nesta apresentação, Person é o Label e os demais itens são suas


propriedades. Em uma representação objetiva para um modelo
relacional, teríamos uma estrutura neste molde, como demonstrado
na Tabela 1, onde é apresentado o modelo de uma estrutura
em tabela (padrão de banco de dados relacional) para facilitar a
compreensão de uma estrutura de banco de dados não relacional
utilizando Neo4J.

131
Tabela 1 - Relação de estrutura não relacional
com modelo relacional

PERSON
Id INT
BORN CHAR
NAME VARCHAR

Fonte: elaborada pelo autor.

Como um banco de dados não relacional armazena informações não


estruturadas, é possível ter outro nó com características similares, com
propriedades diferentes e até ter nós-filhos que não existam em outro
nó de mesma natureza – o que reforça as vantagens atreladas a bancos
não relacionais em detrimento aos relacionais, conforme demonstra
Pereira et al. (2017, p. 4):

O antigo modelo relacional são fracos ao manusear relacionamento


entre dados, pois, eles fazem esquemas rígidos dificultando a inclusão
de diferentes conexões ou adaptações para as novas requisicões de
negócio. O banco de dados em grafos não é apenas eficiente para o
relacionamento de dados, eles tambem são flexíveis quando um modelo
de dados é expandido ou conforme a necessidade de mudança da regra
de negócio. (PEREIRA et al., 2017, p. 4)

4. Sintaxe Cypher

A seguir, iremos listar algumas das sintaxes mais utilizadas para


administração de dados dentro do Neo4J e para isso utilizaremos a
linguagem Cypher, que é uma linguagem declarativa bastante similar
ao SQL (SOUZA, 2016). Obviamente que não seria possível apresentar
todas as sintaxes e combinações possíveis dentro deste curso. Assim,
recomendamos como base de pesquisa e estudos extras o próprio site

132
do Neo4J, que vem com uma documentação completa para servir de
guia durante o desenvolvimento de uma base de dados.

ASSIMILE
A linguagem Cypher é bastante rica em recursos e é
declarativa, ou seja, vai na contramão das linguagens
convencionais e não demonstra como o algoritmo deve
se comportar, mas sim, o que ele deve executar. Isso
significa que, a priori, ainda que haja inversão na sequência
dos comandos dentro da linguagem, se a lógica e sintaxe
estiverem corretas, a execução ocorrerá sem erros.

4.1 Sintaxes e comandos de sistema

• :help<topic>: é um comando de sistema. Utilize o help seguido


do nome do comando desejado para que o Neo4J lhe apresente
informações a respeito deste comando.
• :server disconnect: interrompe a conexão com o banco de dados.
• :server connect: inicia a conexão a um banco de dados.
• :server status: mostra o status atual de um banco de dados.
• :sysinfo: mostra um log em tempo real de tudo o que está
ocorrendo dentro da estrutura do sistema.
• :queries: apresenta as queries que estão ativas em background.
• CREATE: cria nós e relacionamentos.
• MATCH: realiza consultas, similarmente ao SELECT dos bancos de
dados relacionais.
• RETURN: apresenta o valor criado após a execução de uma Query.
• WHERE: é uma cláusula de restrição, assim como nos bancos
relacionais.
• SET: realiza atualizações, similarmente ao UPDATE de bancos
relacionais.

133
• REMOVE: apaga um determinado registro, assim como o DELETE
dos bancos de dados relacionais.
• MERGE: cria um nó-filho de um nó específico.
• CONTAINS: similarmente à cláusula IN do MySQL, permite inserir
uma lista de possíveis resultados aceitos para uma consulta.

4.2 Criando uma estrutura própria com Cypher

A criação de um nó vazio se dá através da seguinte sintaxe:

CREATE ()

Dentro dos parênteses, é o local em que inserimos o conteúdo do nó


(Label e propriedades). O comando acima, se executado, criará um nó
sem nenhum label atribuído, sem exibir o resultado da operação na tela.

É possível, ainda, atribuir uma variável (o que é totalmente opcional)


ao nó, e visualizarmos o conteúdo que acabou de ser criado; para isso,
utilizamos o RETURN:

CREATE (variavel ) RETURN variavel

Para que os nós recebam Labels e propriedades, utilizamos a


seguinte sintaxe:

CREATE (var :usuarios) RETURN var

Algumas regras a serem observadas:

• Na sintaxe anterior, o primeiro valor, se isolado, será sua variável.


• Caso não haja variável, o nome da Label deve iniciar com
dois pontos.
• Nomes de Labels são case-sensitive, ou seja, usuario não é a
mesma coisa de Usuario.

134
No processo de criação de um nó, é possível inserir a criação de
seus nós-filhos:

CREATE (var :usuarios:professores) RETURN var

As propriedades de um Label devem ser adicionadas dentro de


chaves (vamos utilizar o recurso de variáveis para visualizar os dados
previamente criados):

CREATE (var :usuarios:professor{nome:’Antonio da Silva’,


idade:’47’}) RETURN var

O Neo4J irá criar sua estrutura gráfica sempre com associação de cores
para facilitar a identificação dos nós por categorias. A quantidade de
propriedades também é relativa, podendo ser diferente entre os nós.

Para consultar os registros inseridos no banco, basta utilizar a sintaxe do


comando MATCH:

MATCH(n) RETURN n

Em Bancos Relacionais, para que uma busca ao banco de dados fique


mais direcionada, utilizamos a cláusula WHERE – em combinação com
outras cláusulas restritivas. Em bancos não relacionais utilizamos o
mesmo comando:

MATCH (var) WHERE id(var) = 42 RETURN (var)

Os números de ID atribuídos pelo banco de dados são dinâmicos, ou


seja, mutáveis e gerenciados pelo próprio banco. No exemplo acima,
utilizamos o ID 40, mas em seus testes você deverá utilizar um ID que
esteja previamente criado em sua estrutura. O mesmo procedimento de
consulta pode ser feito com Labels:

MATCH (var:professor) RETURN (var)

135
É possível ainda navegar entre todos os nós relacionados de um
banco, bastando apenas inserir a sequência hierárquica entre eles no
próprio comando:

MATCH (var usuario:professor:estadual) RETURN (var)

A consulta direta pela propriedade (em uma alusão ao campo de uma


tabela de um banco de dados relacional seria):

MATCH (var) WHERE var.nome = “Antonio da Silva” RETURN


(var.nome)

Esta consulta resultará na listagem de todos os dados, organizados


pela propriedade nome de nosso banco de dados. A mesma lógica
pode ser aplicada a qualquer outra propriedade existente, exceto o
campo ID, que é criado pelo próprio campo, por isso, possui regras
específicas.

Consultas mais elaboradas podem ser realizadas utilizando-se conjuntos


de propriedades. Por exemplo:

MATCH (n),(m) WHERE n.nome = “Antonio da Silva” AND


m.idade = “47” RETURN (n),(m)

Através da cláusula CONTAINS é possível retornar possíveis valores


aceitos para uma determinada propriedade. Para que esta estrutura
funcione, é necessário que, na criação de seus nodes, você tenha
definido os valores para as propriedades com uma estrutura específica.
Por exemplo:

CREATE (var :cidades{nomeCidade:’São Paulo, Belém, Rio


de Janeiro’}) RETURN var

136
Com esta estrutura, é possível realizar consultas utilizando-se a cláusula
CONTAINS, que analisará se um determinado registro contém um ou
mais valores aceitos:

MATCH (n) WHERE n.nomeCidade CONTAINS “São Paulo” OR


n.nomeCidade CONTAINS “Rio de Janeiro” RETURN n

4.3 Relacionamento entre nodes

Os relacionamentos dentro do Neo4J são bastante intuitivos e podem


ser do tipo PERTENCE/CONTÉM. Para nossos exemplos, utilizaremos a
seguinte estrutura:

CREATE (e :Estado{nomeEstado:”RJ”})

CREATE (c :Cidade{nomeCidade:”Macaé”})

RETURN e, c

Em seguida, realizamos uma consulta (MATCH) e, dentro da estrutura


desta consulta, realizamos o relacionamento entre os nodes:

MATCH (c :Cidade), (e :Estado)

WHERE (c.nomeCidade) = “Macaé”

AND (e.nomeEstado) = “RJ”

CREATE (c)-[r :Pertence]->(e)

RETURN c, e

Esta estrutura retornará o seguinte resultado gráfico, conforme Figura 8,


que demonstra o relacionamento do tipo PERTENCE entre dois nodes.

137
Figura 8 – Resultado de consulta com relacionamentos

O,splaymg 2 nodes, 1 relahonsh1ps

Fonte: elaborada pelo autor.

É possível ainda estabelecer um relacionamento bidirecional, ou seja, da


mesma forma que a cidade de Macaé pertence ao estado RJ, RJ contém
a cidade de Macaé. Para isso basta digitar o mesmo trecho de código
acima ajustando as configurações da linha 4:

MATCH (c :Cidade), (e :Estado)

WHERE (c.nomeCidade) = “Macaé”

AND (e.nomeEstado) = “RJ”

CREATE (e)-[r :Contem]->(c)

RETURN c, e

Esta execução retornará à estrutura gráfica apresentada na Figura 9.

138
Figura 9–Relacionamento Bidirecional
· 1 ª d e), (e :Estado) WHERE ( c.norneC1dade)

■■■■■■
$ MATCH (e ·Cºd . = "Macaé" AND e.n...

Fonte: elaborada pelo autor.

Por se tratar de um banco com dados não estruturados, o Neo4J não


evitará redundâncias, ou seja, ele aceitará dados duplicados, inclusive
em suas relações. Isso significa que, a cada criação de relacionamento,
uma nova instrução será feita, e um novo relacionamento ocorrerá. Para
evitar este tipo de cenário, recomenda-se o uso do MERGE ao invés do
comando CREATE:

MATCH (c :Cidade), (e :Estado)

WHERE (c.nomeCidade) = “Macaé”

AND (e.nomeEstado) = “RJ”

MERGE (e)-[r :Contem]->(c)

RETURN c, e

139
5. Conclusão

Conhecemos nesta aula o banco de dados não relacional Neo4J e um


pouco de sua estrutura, bem como as suas peculiaridades. Vimos,
ainda, a linguagem declarativa Cypher, que é bastante intuitiva e de fácil
compreensão, com cláusulas similares às da linguagem de bancos de
dados relacionais, SQL.

O Neo4J é uma ferramenta bastante completa e que requer um estudo


muito mais aprofundado, ou seja, é necessário que você dispense
algum tempo para aprofundar-se na ferramenta e conhecê-la com mais
detalhes, tomando como ponto de partida os conteúdos ministrados
nesta aula, em conjunto com os materiais complementares.

TEORIA EM PRÁTICA
Pressuponha que você fosse um DBA (data base
administrator) e precisou utilizar uma estrutura NoSQL com
o Neo4J para armazenar os dados de uma grande rede de
supermercados com atuação em mais de 10 países. Elabore
a estrutura deste banco não relacional, baseado em grafos,
apontando os nós necessários e relacionamentos existentes
entre eles. Atente aos detalhes que o projeto precisa ter:
Cada país tem:
• Um tipo de moeda.
• Um idioma.
• Um leque diferenciado de produtos.
O mercado pode:
• Coexistir em vários estados do mesmo país.
• Coexistir em várias cidades do mesmo estado.
• Ter mais de uma loja física em metrópoles ou capitais.

140
Os produtos comercializados devem ser separados em 3
(três) grandes categorias:
• Bebidas.
• Vegetais.
• Industrializados.
• Proteínas (carnes de uma forma geral).
Cada categoria de produto deve ter uma particularidade
de venda, por exemplo, as carnes são vendidas por quilo,
enquanto as bebidas, por litros.

VERIFICAÇÃO DE LEITURA

1. Cada nó no Neo4J, por exemplo, é equivalente a tabelas


(entidades) de bancos relacionais, porém, ao invés
de possuir colunas para armazenamento de dados,
possuem subelementos ligados a si, responsáveis por
alocar os valores. Estes nós, em bancos não relacionais,
também podem ser chamados de:

a. Arestas.
b. Nodes relacionais.
c. Relacionamentos.
d. Colunas.
e. Vértices.

2. Geralmente a requisição de dados de um banco requer


um certo nível de complexidade para se agrupar vários
dados dispersos em um mesmo resultado, gerando
uma informação de valor. Esta união de dados pode ser
denominada relacionamento. Sobre relacionamentos

141
existentes em bancos orientados a grafos, é correto
afirmar que:

a. Eles devem ser unidirecionais.


b. Eles devem ser bidirecionais.
c. Eles podem ser bidirecionais.
d. É recomendado que sejam duplicados.
e. É recomendado o uso do EXCLUSIVE para que não
haja duplicação.

3. Conhecer a estrutura de bancos não relacionais


orientado a grafos é o primeiro passo para tornar-se
especialista na área. Além dos nomes, é necessário,
prioritariamente, conhecer o conceito que envolve
a estrutura de forma a manuseá-la de maneira mais
eficiente. Desta forma, quanto à estrutura do Neo4J –
tomado como exemplo, podemos afirma que:

a. Labels são os nomes atribuídos aos vértices.


b. Nodes de tipos iguais podem ter quantidades
diferentes de propriedades.
c. Arestas podem ser chamadas de propriedades.
d. Propriedades devem ser iniciadas com letras
maiúsculas.
e. Cada Vértice deve ser único.

Referências
NEO4J. What is a Graph Database? Disponível em: <https://neo4j.com/developer/
graph-database/>. Acesso em: 25 Ago. 2019.
PEREIRA, Evelym Maria de Lourdes Rondon. Banco de dados orientado a grafos
com dados de artigos científicos. 2017. 17 f. TCC (Especialização em Banco

142
de Dados)–Universidade Federal de Mato Grosso, Instituto de Computação,
Cuiabá, 2017.
SOUZA, Talita de Paula Cypriano. Aplicação de banco de dados baseados em
grafos no controle de redes de computadores. 2016. 1. recurso online. 79
p. Dissertação (mestrado)–Universidade Estadual de Campinas, Faculdade de
Engenharia Elétrica e de Computação, Campinas, SP. Disponível em: <http://www.
repositorio.unicamp.br/handle/REPOSIP/305425>. Acesso em: 07 out. 2019.

llJiii,; Gabarito

Questão 1 – Resposta: E.
Resolução: nodes ou nós também podem ser chamados de vértices.
Questão 2 – Resposta: C.
Resolução: a bidirecionalidade pode ocorrer entre vários nodes
(embora não seja obrigatória).
Questão 3 – Resposta: B.
Resolução: bancos de dados não relacionais não possuem dados
estruturados, e isso permite que eles armazenem informações
com estruturas distintas, ainda que sejam informações de um
mesmo tipo.

143
Bons estudos!

144

Você também pode gostar