5_banco de dados não relacionais

Prévia do material em texto

W
BA
07
51
_v
1.
0 
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 
http://www.kroton.com.br
 
 
 
 
 
 
 
 
 
 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 
CPFEB Telefone Client e 1 n) 
Nome 
Venda 
Id 
Cod_Produto 
CPF _Cliente 
Data 
Produtos 
f-----e Codigo 
i-oNome f-o varidade 
--------
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 
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. 
SegundoSilberschatz (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 
1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
~~ 
ven.i.. J ~ 
---e Cod_Produto 
CPtF _ Olien1te 
O.ata 
Id 
l
Create table Capitão 
Id int p rimary key , 
Nome varchar (SO ) not nall 
) ; 
1
Create table Navio ( 
Codigo int p rimary key , 
Nome varchar (80 ) not nall , 
Id_Capitao char (l ) not nall , 
Foreign key Id_Capitao references Capitao (Id) 
.> ; 
Figura 2 – Chaves Estrangeiras 
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 
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 
de deixar o BD 
escalável, porém 
a sua projeção 
é complexa. 
Essa é a maior 
vantagem do BD 
relacional, pois a 
maior preocupação 
está nos 
relacionamentos. 
Existe garantia de 
disponibilidade, desde 
que a demanda de 
inserções, exclusões e 
consultas consecutivas 
não sejam de 
grande volume. 
BD não 
Relacional 
Por não possuir 
uma estrutura com 
rigor no tipo de 
dado a ser recebido, 
esse tipo de BD é 
altamente escalável. 
Não existe 
nenhuma garantia 
de consistência 
dos dados. 
Possui grande 
disponibilidade, pois 
permite grandes 
cargas de dados. 
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 
 
 
 
 
 
Disponibilidade 
• 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 
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 
recebemuma 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 
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 Comentarios : [ 
20 {Us uaria : 1 voão 1 , comentaria : 'Ótima opção pa=a me~s projetas' }, 
21 {Usuario : 'Maria' , comen taria : 'H'J.ito utilizado pelas empresas' } , 
22 {Usuaria : 'vosé • , comentario : 'Utilizado em alguns jogos online• } 
23 
24 } 
Figura 5 – Script JSON 
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 
 
 
 
 
'40 CREATE KEYSPACE IF NOT EXISTS "teste" 
'41 WITH replication = { 'class' : 'Sirr.pleStrategy' , 'replication _ factor' : 1 } ; 
'42 
'43 
.g.g 
'45 
'46 
'47 
.g 8 
'49 
CREATE TABLE "teste" . "contatos" 
Id uuid , 
Nome t ext , 
Email tex t , 
Wbats app tex t , 
PRIMARY REY (Id) 
) ; 
Figura 7 – Exemplo de CQL 
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 
gerenciamentode 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 
https://franz.com/agraph/allegrograph/
https://www.cs.berkeley.edu/brewer/cs262b-2004/PODC-keynote.pdf
https://www.cs.berkeley.edu/brewer/cs262b-2004/PODC-keynote.pdf
http://cassandra.apache.org/
https://www.couchbase.com/
https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
http://www.wampserver.com/en/
https://www.mongodb.com/
http://www.orientdb.com/docs/last/
 
 
► 
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 
https://www.python.org/
https://redis.io/
https://dcomp.sor.ufscar.br/verdi/topicosCloud/nosql_artigo.pdf
https://dcomp.sor.ufscar.br/verdi/topicosCloud/nosql_artigo.pdf
https://learn.couchbase.com/store?utf8=%E2%9C%93&ss=1&ct=78327&commit=Filter
https://learn.couchbase.com/store?utf8=%E2%9C%93&ss=1&ct=78327&commit=Filter
 
 
 
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 
 
 
 
7 - create table tbl _ u ser { 
e Id int not null primary lk!ey a u to increment , 
9 Nome varcha.r i(SO ) not null , 
10 Senha. varchar (32 } not null 
11 ) ; 
• 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 
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 feitasnas bases de dados terão os resultados 
30 
 
 
Metada dos 
~ ~ 
Caráter Técnico Caráter de Negócios 
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 
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 
 
 
 
 
 
 
 
 
 
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> 
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 
Fonte: elaborada pelo autor. 
34 
 
 
Declaração XML Referências 
Tags Texto 
~ / 
---i ---A-tr-ib-ut-0s--~1· 
Assim como qualquer outra linguagem, o XML possui regras de sintaxe, 
estruturadas conforme apresentado na Figura 4. 
Figura 4 – Estrutura da sintaxe XML 
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 
 
 
 
 
 
 
 
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 <texto>Vamos e ,s to.dar NoSQL ???-</ texto> 
15 </ mensagem> 
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 
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 
 
 
 
9 " xml v ersion = "1. O"?> 
10 < !--Essa linha representa um comentário--> 
!! - <mensagem> 
12 <para>Grupo de alunos</ para> 
<de>Serginho Nunes</ de> 
<assunt o>Recado! </ assunto> 
< ! --Norr,e do re:n:ecence --> !3 
B 
15 
'.!.6 
<texto>Vamos estudar NoSQL???</ texto> <!--Linha da mensagem--> 
</ mensagem> 
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 
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 
http://www.serginhonunes.com.br
http://www.serginhonunes.com.br
 
 
 
 
 
 
1 
2 
3 
4 
5 
6 
- k ! DOCT YPE e l e me n to DTD inden t i f i cai.dor 
[ 
] 
decl a r ai.çãa _ 1 
d e c l arai.çãa_ 1 
d e c l arai.çãa _ n 
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 
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 
 
2 
3 
'4 
5 
6 
7 
9 
10 
<:xm!. v e rsion= 111.011 ?>: 
l<' OOCTYPE 
< !IELEMENT 
email [ 
me nsagem (para, de,assunt o ,texto) > 
LEMENT pa.ra (#PCDAl'A) 
LEMENT de (;\:PCDATA) > 
LEMENT assunto (#PCDAI'A) 
LEMENT texto ( #PCDAl'A) > 
11 ]> 
_2 
13 - <aviso> 
.'.!.4 <para.>Grupo de alunos< / para> 
~5 <de>Serginho Nunes</ de> 
16 <assunto>Recado! </ assunto> 
17 <texto>Vamos estudar NoSQL???< / texto> 
º </ aviso> 
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 
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 
 
 
 
 
 
 
 
 
 
!<" ? xml ve:::sion = 1 1 1. O 1 1 ?~ 
~ < ! DOCTYPE S Y STEM "' e x e mp l aEx ter :n.o . dt~ " 
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 > 
<assunto>Re cado !</ assunto> 
<texto>Vamos est udar NoSQL???</ texto> 
</aviso> 
Figura 9 – DTD extreno 
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 
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ó 
disponibilizousuporte 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 
https://neo4j.com
https://mongodb.com
https://postgresql.org
https://dev.mysql.com
 
 
 
 
 
 
9 
!O 
11 
12 
13 
14 
XML 
<,xml ve r sio~ "' " 1 .0" s 
l
<regi:stro> 
<id>l </J.d> 
<nome>Serginho Nones</ nome> 
<funcao>Aotor</funcao> 
</ reg1.5'tro> 
1 
1 
1 
1 
1 
1 
2 
3 
1 
JSON 
l {,. id" : - , " nome n : 11 Sergir-.ho Nu!'les 11 , "fu."'lcaoº : "Autor" } 
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 
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 
 
 
 
 
 
5 - rre stu dantes'" : [ 
6 { "primeiroNome r1 : rr'Ayrton r1 , nul timoNome rr : rrsenna rr•} , 
7 
9 
{ "primeiroNomerr : rr'Allaor' , rr'ultimoNome'rr : rrTu ringrr}, 
{ r'p:rimeiroNome r1 : rr'Eob rr' , r1u1 timoNome" : ª Mairley rr} 
] 
11 - { 
12 "Nome" . " Se rginhon , . 
13 r' Idade n . 42 , . 
11 r'Peso " . 90 . 5 , . 
15 "Casado " : tra.e , 
16 rr instagiramrr : nu.11 
17 } 
Figura 12 – Exemplo de Script JSON 
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 
Fonte: elaborada pelo autor. 
45 
 
 
 
 
 
1 - < ?p l::.p 
2 $my0bj ->nom.e = "Sergin:'1a" ; 
3 $my0bj - >idade = 42 ; 
4 SmyObj - >c.idade = "São Paulo" ; 
5 
6 
í 
o 
9 
$myJSON = json_encode ($my0bj } ; 
echo $myJSON; 
? > 
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 
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 
 
 
 
 
 
 
 
 
 
1 DTD indenti f icado JL 
2 [ 
3 declaJLaçã.o_ 
-4 declaJLaçã.o_ 
5 declaJEação_ 
6 ] >l 
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çãoorientada 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 
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 
https://tools.ietf.org/html/rfc7159
https://www.techtudo.com.br/noticias/2017/06/metadados-como-suas-fotos-online-revelam-mais-do-deveriam-na-internet.ghtml
https://www.techtudo.com.br/noticias/2017/06/metadados-como-suas-fotos-online-revelam-mais-do-deveriam-na-internet.ghtml
https://dev.mysql.com/doc/refman/5.7/en/json.html
https://www.mongodb.com/
https://neo4j.com/developer/guide-import-json-rest-api/
https://www.postgresql.org/about/news/1481/
https://www.w3.org/standards/xml/
 
 
 
 
 
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 
1 - { 
2 nidn : nl rr ' 
3 'í' f irstn a me" : rr J an es rr , 
4 
5 
6 
9 
_J 
11 
12 } 
r11 astn am.e " : rr Japlinrr , 
r' a d diress rr : { 
} , 
rrstreet rr : "Cloud Street r, , 
rrc i t y rr : nLo s Ang e l esrr , 
"'sta te rr : r•CA'" , 
"'z i prl : rr 9 o s o s rr 
nhobbi es rr : [ rrc an taJt: n , rr campo :r: rr] 
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 
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 
Chave-valor Orientado a documentos 
-------.~~-Estrutura encontrada 
no JSON. 
Figura 2 – Chave-Valor X Orientado a Documentos 
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 
DB- Engines Ranking ... ... 
400 
- MongoDB 
200 
+ Redi< 
100 
Cassandra 
... .. 
] 40 + HBase 
u e 
~ 20 .. 
8 Am.uon DynamoDB ., - N•n4J 
s .,, 10 
4 
V-
2 
e ~ebruarv 2018. 08-EnQones.com 
2013 2014 20 ü 2016 201/ 2018 1/11 'f' 
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 
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 
 
 
 
1 - create· ta.ble t b l _ u ser ( 
2 I d int not uull. primary key au 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 ); 
_ 4 - db . doe_ u se r . ins e rt ( { 
_5 I d : rr 1 rr , 
_6 Nome : rrserginho rr , 
- 7 I dade : rr 42 rr , 
~ Prof i ssai.o : rrProfess o rn 
19 } ) 
Figura 4 – Criação de tabelas em SQL 
Fonte: elaborada pelo autor. 
• JSON (MongoDB): 
Figura 5 – Criar registro JSON 
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 
 
 
 
 
-º d r op t abl e tbl u ser ; 
db . doe_ user . drop O 
sel e ct * f r om t bl u ser ; 
23 db . doc_ u 3er . f ind ( ) 
Figura 6 – Exemplo de script para excluir tabela em SQL 
Fonte: elaborada pelo autor. 
• MongoDB: 
Figura 7 – Excluir registro JSON 
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 
Fonte: elaborada pelo autor. 
• MongoDB: 
Figura 9 – Exemplo de seleção de dados em JSON 
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 
 
 
 
 
_4 
15 
25 
26 
27 
sel e ct • f r om t b l u seI 
whe r e I d = 1 ; 
db . doc_ u ser . f ind { 
~ ~ Id : rr1 n 
) 
17 sel e ct count ,C * ) f r om tbl u seI ; 
30 d.b . dac_ u ser . caunt O 
• SQL: 
Figura 10 – Exemplo de seleção de dados com condicinal em SQL 
Fonte: elaborada pelo autor. 
• MongoDB: 
Figura 11 – Exemplo de seleção de dados com condicional em JSON. 
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 
Fonte: elaborada pelo autor. 
• MongoDB: 
Figura 13 – Exemplo de contagem de registros em JSON 
Fonte: elaborada pelo autor. 
60 
1~ 
[m
i 
►
I 
>< 
Q,) 
i:: 
,,..., 
<.:> 
-i::: 
:e 
-
-1,.) 
!Ci 
<.:> 
<.:> 
o 
,,..., 
Q,) 
-1,.) 
!Ci 
-1,.) 
!Ci a 
V
 
Q,) 
..... 
.... 
Q,) 
Q,) 
.:7
):. 
0
■
 
::: 
::> 
...::l 
i::~
 
:. 
..... 
IZ
 
Q,) 
• .... 
Q,) 
~
 
o 
Q,) 
" 
:::) 
,.,; 
:: 
:. .... 
Q,) 
<.:> 
<.:> 
!Ci 
o 
O
.i:i 
~ 
sr 
Q,) 
..... 
Q,) 
E
 
:,, 
.., !Ci 
co
 
:. 
.., 
~ 
•,-4 
(,') 
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 
&: 
l
i
 
X
 
.... 
-1,.) 
..... 
.... 
i:: 
-
!Ci 
-1,.) 
0.l"i::i 
X
 
..... 
o 
.., 
E
 
=i. 
.... 
i:: 
..... 
.. 
. .... 
. .... 
:. 
o 
.i:i 
!Ci 
<+. 
-1,.) 
::: 
o 
!Ci 
E
 
-1,.) 
-
!Ci 
<+. 
-1,.) 
i:: 
E
 
t 
o 
<.:> 
:. 
Q,) 
e: 
i:: 
Q,) 
o 
::i::: 
..... 
Q,) 
.., 
..... 
Q,) 
<.:> 
~
 
=i. 
..... 
E
 
.i:i 
.......... 
,...., 
o 
G? 
" 
:,, 
-i::: 
.:7) 
i:: 
i:: 
i:: 
i:: 
.i:i 
..... 
o 
i:: 
Q,) 
Q,) 
Q,) 
Q,) 
Q,) -
.... 
·• •l""I 
.., 
.., 
-1,.) 
'-1
,.) 
Q,) 
:::) 
::: 
-1,.) 
=i. 
-i:::::: 
G? 
(,') 
t,') e., "' 
<.:> 
.... 
Q,) 
i:: 
o 
Q
,)•.-< 
.......... 
Q
,)•.-< 
..... 
u 
~
 
Q,) 
-i::: 
!Ci .... 
..:: .... 
l""'"tl""'"'ll""'"'l,...-1 
::> 
Q
 
" 
E
.-<
 
..,-,:: 
-i:::-i:::·'"'"i::i 
:. 
o 
:: 
-i::: 
E
 
o 
i:: 
i:: 
i::<+. 
i:: 
Q,) 
i:: 
.:7) 
i:: 
0
4
<
 
-1,.) 
!Ci 
!Ci 
!Ci 
!Ci 
G? 
o 
i:: 
::r, 
!Ci 
<.:> 
:. .., 
.., 
-1,.) 
!Ci 
-1,.) 
..... 
o 
!Ci 
Q,) 
,:i·.-< 
........... .., ..... 
.:7) 
-1,.) 
:e 
E
 
G? 
.:7)..:: 
.., e: 
.:7) i:: 
i:: 
!Ci e: 
i:: 
!Ci 
-1,.) 
e: .., 
1, ..... i::·.-<•.-<-,::•.-< 
..... 
r, 
!Ci 
~
 
::: 
..... 
...... •,.,t ......
...... 
~