Introdução a Bancos NoSQL

Prévia do material em texto

Introdução aos Bancos de Dados NoSQL: Evolução e Comparação
1. Evolução dos Modelos de Dados
A organização dos dados evoluiu significativamente desde os primórdios da computação, impulsionada pela necessidade de maior flexibilidade, integridade e capacidade de processamento.
Primeiros Modelos
· Modelo Hierárquico: Estruturado em uma relação de tipo pai-filho entre as tabelas. Exigia que todo o projeto do banco de dados fosse definido de forma rígida e hierárquica desde o início.
· Modelo em Rede: Organizava os dados em conjuntos de registros interligados por ponteiros. Apresentava alta complexidade tanto no desenvolvimento do projeto quanto no uso e manutenção, o que limitava sua escalabilidade e facilidade de manipulação.
O Modelo Relacional
Surgido em 1970, o modelo relacional revolucionou o mercado e ainda detém aproximadamente 70% do uso atual. Seus principais fatores de sucesso incluem:
1. Simplicidade e Uniformidade: Utiliza tabelas com atributos atômicos e fundamentação matemática baseada em Álgebra e Cálculo Relacional, além da linguagem padronizada SQL (Structured Query Language).
2. Propriedades ACID: Garante o controle rigoroso de transações por meio da Atomicidade, Consistência, Isolamento e Durabilidade. Diferencia-se dos modelos NoSQL por não permitir atributos multivalorados ou compostos na primeira forma normal.
3. Modelo Entidade-Relacionamento (MER): Facilitou o design gráfico dos bancos de dados e a compreensão da estrutura da aplicação, simplificando consultas complexas envolvendo múltiplas tabelas (joins).
Sistemas Gerenciadores de Banco de Dados Relacionais-Objeto (SGBDRO)
Com o avanço da Orientação a Objetos (OO), surgiram os SGBDROs, que incorporam recursos de OO aos sistemas relacionais, como a criação de novos tipos de dados e o suporte à herança.
· Exemplos de SGBDs Comerciais/Código Aberto: Oracle, Microsoft SQL Server, PostgreSQL, IBM (DB2 e Informix), MySQL e SQLite.
Obs.: O MongoDB não é um SGBDRO, mas sim um sistema NoSQL orientado a documentos.
2. Classificação dos Tipos de Dados
O aumento da complexidade das aplicações e a necessidade de processamento rápido levaram à classificação dos dados em três categorias:
1. Dados Estruturados
· Possuem estrutura definida rigidamente antes da carga dos dados. Exemplo clássico: tabela de um banco de dados relacional.
· Dublin Core: Para estabelecer padrões em documentos na web, utiliza-se o metadado Dublin Core, composto por 15 elementos básicos:
	Elemento
	Descrição
	Title
	Nome pelo qual o recurso é conhecido.
	Creator
	Autor (pessoa, organização ou serviço).
	Subject
	Assunto expresso por palavras-chave.
	Description
	Descrição livre, incluindo tabelas ou referências.
	Publisher
	Entidade responsável pela publicação.
	Contributor
	Entidade que auxiliou na publicação.
	Date
	Data de criação/disponibilização (AAAA-MM-DD).
	Type
	Categoria do recurso.
	Format
	Formato da mídia ou dimensões.
	Identifier
	Chave única (ex: URI).
	Source
	Fonte de onde o recurso se origina.
	Language
	Código do idioma (2 letras).
	Relation
	Relação com outro recurso.
	Coverage
	Abrangência espacial ou temporal.
	Rights
	Informações sobre direitos autorais (Copyright).
2. Dados Semiestruturados
· São dados irregulares e incompletos que não seguem um esquema pré-definido rígido. A estrutura pode variar entre registros.
· Exemplos: Arquivos XML (Extensible Markup Language), Bibtex (referências bibliográficas) e arquivos de testes de RNA.
· Flexibilidade: No XML, por exemplo, um registro pode conter 3 atributos em uma tag, enquanto outro registro na mesma base pode conter 16, demonstrando a adaptação à variação dos dados.
3. Dados Não Estruturados
· Não podem ser descritos em tabelas pré-definidas e representam cerca de 80% dos dados atuais.
· Exemplos: Comentários em redes sociais, vídeos, áudios, imagens, mensagens instantâneas, e-mails e relatórios exportados.
3. Bancos de Dados NoSQL vs. Modelo Relacional
· O termo NoSQL (Not Only SQL) refere-se a modelos projetados para lidar com grandes volumes de dados (Big Data), alta escalabilidade e flexibilidade.
Principais Diferenças
	Característica
	Modelo Relacional
	Modelo NoSQL
	Esquema (Schema)
	Fixo e pré-definido.
	Dinâmico/Flexível.
	Linguagem
	SQL (Padronizada).
	Variada (UnQL, Cypher para grafos etc.).
	Escalonamento
	Vertical (Scale-up): Aumento de hardware no mesmo servidor.
	Horizontal (Scale-out/Sharding): Distribuição em vários nós/servidores.
	Consultas
	Eficiente para consultas complexas e joins.
	Focado em conjuntos de atributos; joins não são nativos.
	Transações
	Rigoroso (Propriedades ACID).
	Flexível (Teorema CAP ou propriedades BASE).
	Desempenho
	Pode sofrer em volumes massivos devido aos joins.
	Projetado para alto desempenho em sistemas distribuídos.
Modelos de Dados NoSQL
Os bancos NoSQL utilizam quatro estruturas principais para atender diferentes demandas:
1. Baseado em Documentos: Armazena dados como documentos (ex: JSON/BSON).
2. Chave-Valor: Armazenamento simples de pares de chaves e valores.
3. Orientado a Colunas: Armazenamento otimizado para leitura de colunas específicas.
4. Baseado em Grafos: Focado em modelar relacionamentos complexos entre entidades (ex: Neo4j usando a linguagem Cypher).
Teorema CAP e Controle Transacional
Enquanto os bancos relacionais priorizam a consistência total (ACID), os bancos NoSQL baseiam-se no Teorema CAP, que lida com o equilíbrio entre:
· C (Consistência): Todos os nós veem os mesmos dados ao mesmo tempo.
· A (Disponibilidade/Availability): Garantia de que cada requisição recebe uma resposta.
· P (Tolerância a Partição): O sistema continua funcionando apesar de falhas na rede.
A maioria dos sistemas NoSQL prioriza a Disponibilidade e a Tolerância a Partição, oferecendo uma consistência eventual para permitir maior escalabilidade.
Exercícios
1. Assinale a afirmativa incorreta em relação aos modelos de dados hierárquico, em rede, relacional, relacional-objeto e NoSQL:
a) O NOSQL tem os modelos chave-valor, orientado a documentos e de modo colunar e em grafos.
b) No modelo de dados hierárquico todo o projeto do banco necessitava ser definido de forma hierárquica.
c) Na organização do modelo em rede utilizava-se ponteiros para o acesso aos registros.
d) O modelo relacional-objeto permite criar tipos de dados e usar herança.
e) O relacional tem fundamentação matemática, usa a SQL e segue o Teorema CAP.
2. Assinale a opção que indica a relação incorreta quanto ao tipo de dado e o arquivo usado:
a) E-mail – semiestruturado.
b) Vídeos – não estruturado.
c) Tabela – relacional.
d) Arquivo .xml – semiestruturado.
e) Rede social – não estruturado.
3. Assinale a alternativa correta sobre as diferenças entre os modelos de bancos de dados NoSQL e o modelo relacional:
a) Bancos relacionais geralmente utilizam escalonamento horizontal, enquanto os bancos NoSQL utilizam escalonamento vertical para aumentar desempenho.
b) Nos bancos NoSQL, o esquema é rigidamente definido antes da inserção dos dados, seguindo o mesmo princípio dos bancos relacionais.
c) Os bancos de dados relacionais utilizam o modelo ACID como base para controle transacional, enquanto muitos bancos NoSQL priorizam modelos BASE para maior flexibilidade.
d) Bancos relacionais são mais adequados para armazenar documentos não estruturados, como JSON, do que bancos NoSQL orientados a documentos.
e) Consultas envolvendo múltiplas coleções e junções complexas são mais eficientes e nativamente suportadas em sistemas NoSQL do que em sistemas relacionais.
Modelos de Bancos de Dados NoSQL: Uma Visão Abrangente
1. Banco de Dados Chave-Valor (Key-Value)
O modelo chave-valor é um dos mais utilizados devido à sua simplicidade e alto desempenho. Ele armazena dados como um conjunto de pares, onde uma chave única identifica um valor associado.
Características Principais
· Simplicidade e Flexibilidade: Não há exigência de um esquema fixo (schemaless). Cada registro pode ter um número diferente de pares chave-valor.
· Formatos de Dados: Os valores podem ser objetos binários,textos simples ou documentos em formatos de intercâmbio como o JSON (JavaScript Object Notation).
· Escalabilidade e Disponibilidade: Projetado para alta escalabilidade horizontal, permitindo o particionamento e replicação em clusters, eliminando pontos únicos de falha.
· Ausência de Transações ACID: O controle de transações, réplicas e tolerância a falhas deve ser codificado pelos desenvolvedores na camada da aplicação.
Exemplo de Estrutura (JSON)
No modelo chave-valor, é possível recuperar apenas atributos específicos de um objeto JSON indexado por uma chave:
INSERT INTO pedidos (detalhes) VALUES('{"cliente":"Ana", 
"itens":{"produto":"tablet", "qtd":2}}')
SELECT detalhes->'cliente' AS cliente FROM pedidos
Exemplos de SGBDs e Aplicações
· SGBDs: Redis, Amazon DynamoDB, Memcached, etcd e Microsoft Azure Cosmos DB (que é multimodelo).
· Aplicações Típicas:
· Serviços Financeiros: Análise em tempo real de bolsas de valores.
· E-commerce: Gestão de carrinhos de compras para melhor performance.
· Web e Gaming: Controle de sessões de usuários e armazenamento de dados de sensores (IoT).
· Streaming: A Netflix utiliza o DynamoDB para testes com dados personalizados de milhões de clientes.
2. Banco de Dados Orientado a Documentos
Este modelo evoluiu do conceito de chave-valor, mas com a capacidade de armazenar e organizar conjuntos de pares em coleções.
Características Principais
· Documentos: Cada registro é um documento que contém pares identificador-valor.
· Flexibilidade de Atributos: Permite o uso de identificadores variados, documentos embutidos (aninhados) e listas.
· Formatos Suportados: JSON, BSON (Binary JSON), JSONB (versão mais rápida do JSON usada no PostgreSQL), XML e YAML.
· Performance: Excelente desempenho para ambientes distribuídos e Big Data.
Exemplo de Coleção no MongoDB
O MongoDB é o SGBD orientado a documentos mais popular. Veja como uma postagem de blog pode ser estruturada:
db.postagem.insert([
 {titulo: 'Banco de dados orientado a documentos',
 detalhes: 'É um dos modelos de bancos de dados NoSQL',
 autor: 'curso NOSQL',
 tags: ['banco de dados', 'NOSQL', 'MongoDB'],
 nr_de_likes: 1000 }])
Exemplos de SGBDs e Aplicações
· SGBDs: MongoDB, RavenDB e CouchDB.
· Aplicações:
· Logs de Sistemas: Centralização de eventos de diferentes sistemas para registro de origem e tipo.
· Gestão de Conteúdo (CMS): Blogs e comentários de usuários onde o formato do conteúdo não é pré-estabelecido.
· Catálogos de Produtos: Úteis quando diferentes categorias de produtos possuem atributos distintos.
3. Banco de Dados Colunar (Orientado por Colunas)
Enquanto os bancos relacionais organizam os dados em linhas, os bancos colunares os armazenam em colunas.
Característica:
· Família de Colunas: 
· Uma linha é uma coleção de colunas associada a uma chave; 
· uma família de colunas corresponde a uma coleção de linhas semelhantes.
· Consultas Paralelas: 
· Sua estrutura permite maior consistência e a execução eficiente de consultas paralelas e agregações (como a função SUM).
· Linguagem Própria: 
· O Cassandra, por exemplo, utiliza a CQL (Cassandra Query Language), que suporta comandos similares ao SQL.
Exemplo de Comando CQL (Cassandra)
CREATE COLUMNFAMILY cliente (
 codigo varchar primary key,
 nome varchar,
 cidade varchar)
Exemplos de SGBDs e Aplicações
· SGBDs: Cassandra (criado pelo Facebook), HBase, Google BigTable e Hypertable.
· Aplicações Típicas:
· Contadores: Útil para contadores de visitantes em aplicativos (o Cassandra possui o tipo CounterColumnType).
· Redes Sociais: O Facebook utiliza para controle de mensagens.
· Análise de Logs: Registro de grandes volumes de dados de logs devido à escalabilidade.
4. Banco de Dados Orientado a Grafos
Este modelo foca intensamente nos relacionamentos entre os dados, utilizando uma estrutura baseada na teoria dos grafos.
Características Principais
· Estrutura: Composto por Vértices (nós que representam entidades) e Ramos/Arestas (que indicam os relacionamentos).
· Propriedades: Tanto vértices quanto ramos podem possuir propriedades que descrevem os dados.
· Agilidade na Navegação: Permite percorrer relacionamentos complexos de forma muito mais rápida que em tabelas relacionadas.
· Desvantagem: Possibilidade de redundância ou incoerência nos dados.
Exemplo de Consulta: Neo4J/Cypher.
A linguagem Cypher permite visualizar graficamente os resultados. Uma consulta para listar fornecedores de uma categoria específica seria representada por padrões como: 
(s:Supplier)-->(p:Product)-->(c:Category)
Exemplos de SGBDs e Aplicações
· SGBDs: Neo4J, AllegroGraph, OrientDB, InfiniteGraph e Amazon Neptune.
· Aplicações Típicas:
· Sistemas de Recomendação: Sugestões de compras baseadas no perfil e conexões do usuário.
· Redes Sociais: Análise visual de relacionamentos complexos entre usuários.
· Detecção de Fraude: Identificação rápida de padrões e conexões suspeitas em bases de conhecimento.
· Personalização de Conteúdo: O Google BigTable é utilizado para seleção de anúncios e mídias digitais.
Resumo Comparativo de Modelos e SGBDs
	Modelo
	SGBDs de Exemplo
	Formato/Estrutura Principal
	Chave-Valor
	Redis, DynamoDB, Memcached
	Pares Chave:Valor (Ex: JSON)
	Documentos
	MongoDB, CouchDB, RavenDB
	Documentos em Coleções (JSON, BSON)
	Colunar
	Cassandra, HBase, BigTable
	Famílias de Colunas (CQL)
	Grafos
	Neo4J, OrientDB, Amazon Neptune
	Vértices, Ramos e Propriedades
Nota Importante: O banco de dados Neo4J é estritamente um banco de grafos e não deve ser confundido com modelos de chave-valor. Da mesma forma, o formato JSON é o padrão de intercâmbio mais comum tanto para modelos de chave-valor quanto para orientados a documentos.
Exercícios
1. Assinale a afirmativa incorreta quanto às características dos modelos de dados NoSQL:
a) O modelo chave-valor é o mais usado e é conhecido pelo formato como armazenam os dados, ou seja, utiliza pares de chaves-valores, sendo denominados como key-value pair databases (KVP).
b) Os bancos de dados em grafos são compostos em sua modelagem por nós que representam as entidades de dados, arestas que representam os relacionamentos existentes entre os nós, e propriedades que descrevem os dados armazenados.
c) Assim como no modelo orientado a colunas, o modelo relacional possibilita a escolha da orientação do armazenamento em colunas, semelhantemente ao armazenamento em linhas.
d) Uma linha no banco de dados orientado a colunas, ou colunar, é uma coleção de colunas que tem uma associação a uma determinada chave, e uma família de colunas corresponde a uma coleção de linhas semelhantes.
e) A vantagem principal do modelo orientado a objetos é que ele pode ser listado como a capacidade de suportar conjuntos de conjuntos de pares chave-valor, ou seja, sua característica principal é o armazenamento de documentos.
2. Assinale a opção que indica de forma incorreta exemplos de SGBDs para cada modelo NoSQL:
a) MongoDB –documentos.
b) Neo4J - grafos.
c) Hypertable - chave-valor.
d) CouchDB - documentos.
e) Hbase – colunar.
3. Assinale a opção falsa em relação às indicações de aplicações de uso ou categorias de sistemas de informação mais adequados para cada um dos modelos de bancos de dados NoSQL apresentados:
a) Grafos - uso com sistemas de recomendação para a indicação mais acertada de produtos de acordo com o perfil do usuário.
b) Colunar - plataformas de blogs e contadores de visitantes em aplicativos.
c) Documentos - em aplicativos de comércio eletrônico por conta das diferenças de atributos para as diversas categorias de produtos existentes.
d) Chave-valor- no controle de dados de sessões web.
e) Grafos - análise em tempo real dos serviços financeiros como a bolsa de valores onde há um grande volume de dados a ser processado.
Modelo de Dados NoSQL Baseado em Chave-Valor
1. Introdução ao Modelo Chave-Valor
Os bancos de dados que seguem o modelo chave-valor são considerados os mais simples entre os bancos NoSQL, o que justifica serem amplamente utilizados. Eles são conhecidos como Key-Value Pair Databases (KVP) e armazenamdados em conjuntos de pares, onde uma chave atua como identificador único para um item e o valor armazena o conteúdo propriamente dito.
Exemplos de SGBDs Chave-Valor
· Redis: Focado em alta performance.
· Amazon DynamoDB: Serviço gerenciado e escalável.
· Microsoft Azure Cosmos DB: Banco multimodelo que admite o formato chave-valor.
· Memcached e etcd: Outros exemplos proeminentes do mercado.
· PostgreSQL (HSTORE): Extensão que permite o uso deste modelo dentro de um banco relacional.
2. Características e Performance
A estrutura de armazenamento permite que o valor seja de diferentes tipos, desde tipos simples até listas ou outros objetos chave-valor encapsulados.
Principais Atributos:
1. Padronização de Chaves: Para garantir a qualidade e a administração dos dados, as chaves devem seguir um padrão. Deve-se evitar o uso de chaves excessivamente longas para não comprometer o desempenho.
2. Velocidade e Processamento: Estes sistemas são ideais para aplicações que exigem alta velocidade em leituras e gravações. O ganho de performance ocorre porque o processamento não segue o modelo clássico de transações ACID (Atomicidade, Consistência, Isolamento e Durabilidade) dos bancos relacionais.
3. Escalabilidade Horizontal: Diferente dos bancos relacionais, que costumam escalar verticalmente, o modelo chave-valor é facilmente particionado em clusters. Isso possibilita a escalabilidade horizontal, eliminando o perigo de um ponto único de falha e aumentando a performance global.
Nota sobre Transações: Devido à ausência de suporte completo a propriedades ACID, a responsabilidade de garantir a integridade, replicação e tolerância a falhas muitas vezes é delegada aos desenvolvedores, que precisam codificar essas rotinas na aplicação.
3. O Conceito de Schemaless (Sem Esquema)
Diferente do modelo relacional, que exige a definição prévia da estrutura das tabelas (campos e tipos de dados), o modelo chave-valor é schemaless.
· Flexibilidade: Não há rigidez na definição da estrutura. Registros diferentes podem ter chaves e valores variados dentro da mesma coleção.
· Aplicação Prática: É ideal para cenários onde os atributos podem variar drasticamente, como em postagens de blogs ou sistemas de gerenciamento de conteúdo, onde novos campos podem surgir sem a necessidade de alterar a estrutura do banco.
· Intercâmbio de Dados: Permite o armazenamento de dados em formato JSON, facilitando a integração entre servidores e aplicações web/móveis.
4. Implementação no PostgreSQL: HSTORE
O HSTORE é uma extensão do PostgreSQL (disponível desde a versão 8.4) que permite armazenar conjuntos de pares chave-valor em uma única coluna. É uma ferramenta útil para dados semiestruturados ou linhas com muitos atributos raramente consultados.
Comandos Básicos
Para utilizar o HSTORE, é necessário habilitar a extensão:
CREATE EXTENSION hstore;
Exemplo de Criação de Tabela:
CREATE TABLE livros (
 nr serial primary key,
 titulo varchar(255),
 detalhes hstore);
Exemplo de Inclusão (INSERT): As chaves e valores são citados entre aspas duplas, usando o operador =>.
INSERT INTO livros (titulo, detalhes) VALUES 
('Mastering PostgreSQL 10', '"paginas"=>428, "assunto"=>"PostgreSQL", "ISBN"=>"1788472292"');
5. Evolução: JSON e JSONB no PostgreSQL
Embora o HSTORE tenha sido a primeira forma de trabalhar com chave-valor no PostgreSQL, o uso de JSON e JSONB tornou-se o padrão atual devido à sua compatibilidade nativa com linguagens de programação (como JavaScript) e maior riqueza de recursos.
Comparativo: JSON vs. JSONB
	Característica
	JSON
	JSONB
	Armazenamento
	Armazena uma cópia exata do texto de entrada.
	Armazena em formato binário decomposto.
	Performance de Escrita
	Mais rápida (não requer processamento).
	Mais lenta (requer conversão para binário).
	Performance de Consulta
	Mais lenta (precisa reprocessar o texto).
	Muito mais rápida (suporta indexação).
	Indexação
	Não suporta índices avançados.
	Suporta índices GIN (Generalized Inverted Index).
Manipulação de Dados (Exemplos)
1. Criação de Tabela com JSONB:
CREATE TABLE filmes (
 idfilme serial primary key,
 dados jsonb NOT NULL);
2. Inclusão de Dados com Arrays:
INSERT INTO filmes (dados) VALUES 
('{"titulo": "Filme_A", 
"generos": ["Curta", "Drama"], "publicado": false}');
3. Consultas Específicas:
· Extrair valor como texto (->>):
· Filtrar por chave booleana:
· Verificar se um array contém um valor (@>):
4. Funções de Visualização e Expansão:
· jsonb_pretty(dados): Exibe o JSON de forma indentada e legível.
· json_each(coluna): Expande o objeto JSON em um conjunto de pares chave-valor em linhas separadas.
· jsonb_array_elements_text(coluna): Expande cada elemento de um array em linhas de texto.
6. Diferenciação de Outros Modelos NoSQL
É fundamental distinguir o modelo chave-valor de outros modelos NoSQL para evitar erros de arquitetura.
· Chave-Valor: Focado em simplicidade e velocidade (Ex: Redis, HSTORE).
· Grafos: Focado em dados altamente relacionados e conexões complexas.
· Exemplo: O Neo4j é um banco orientado a grafos, portanto, não se enquadra no modelo chave-valor.
· Documentos: Armazena documentos (como JSON), mas costuma oferecer APIs de consulta mais complexas que o modelo puro de chave-valor.
7. Melhores Práticas e Conclusões
· Indexação: Ao utilizar JSONB, a criação de índices GIN é recomendada para pesquisas eficientes em grandes volumes de dados (milhões de linhas).
· Uso de Operadores: Utilize -> para retornar objetos JSON e ->> para retornar texto, conforme a necessidade da aplicação.
· Atualização de Dados: É possível atualizar apenas uma chave específica usando a função REPLACE() combinada com conversões de tipo (CAST), ou concatenar novos dados usando o operador ||.
Este modelo oferece a flexibilidade necessária para o desenvolvimento moderno de aplicações web e móveis, permitindo escalabilidade horizontal e adaptação rápida a mudanças nos requisitos de dados.
Exercícios
1. Assinale a afirmativa que indica um fator importante para o desempenho dos bancos de dadosNoSQL:
a) A característica de ser schemaless.
b) Não usar apenas a SQL.
c) A escalabilidade vertical.
d) A limitação de que os valores presentes em um conjunto de pares chave-valor sejam do mesmo tipo de dado.
e) Ter suporte de transações diferente do relacional.
2. Assinale a afirmativa correta quanto à criação de tabelas e característica schemaless no modelo chave-valor:
a) Exige a definição da estrutura da tabela.
b) Exige a definição dos tipos de dados utilizados.
c) Não exige a predefinição da estrutura da tabela.
d) Exige a definição da quantidade de tabelas da aplicação.
e) Não exige o uso de um schema, permitindo a criação das tabelas apenas no schema public.
Banco de Dados NoSQL: Modelo Orientado a Documentos e Agregados
1. Introdução ao Modelo Orientado a Documentos
· O modelo orientado a documentos é frequentemente visto como uma evolução do modelo chave-valor. 
· Enquanto o modelo chave-valor armazena dados de forma simplificada, o modelo orientado a documentos permite que cada registro represente um documento completo, organizado em coleções.
Características Principais
· Ausência de Esquema (Schema-less): Ao contrário do modelo relacional, não exige uma estrutura de tabela pré-definida.
· Flexibilidade: Documentos dentro da mesma coleção podem ter estruturas diferentes, embora geralmente compartilhem características semelhantes para fins de organização.
· Unidades de Armazenamento: Os documentos são as unidades básicas (equivalentes a linhas/registros) e as coleções são os conjuntos de documentos (equivalentes a tabelas).
· Complexidade: Um documento pode ser um item simples ou composto (contendo listas ou outros documentos embutidos).
Comparação de Nomenclatura: Relacional vs. Orientado a Documentos
	Modelo Relacional
	Modelo Orientado a Documentos (ex: MongoDB)
	Banco de Dados (database)
	Banco de Dados (database)
	Tabela
	Coleção
	Linha, Registro ou Tupla
	Documento
2. Formatos de Arquivos e Codificação
Os documentos podem ser codificados de diversas formas para armazenamentoe intercâmbio de dados.
· JSON (JavaScript Object Notation): O formato mais utilizado atualmente devido à sua leveza e facilidade de leitura.
· BSON (Binary JSON): Formato binário utilizado internamente pelo MongoDB para otimizar o armazenamento e a velocidade de acesso.
· JSONB: Versão binária do JSON usada no PostgreSQL, que permite indexação eficiente (índices GIN).
· XML (eXtensible Markup Language): Formato hierárquico baseado em tags.
· YAML (Yet Another Markup Language): Focado na legibilidade humana.
· Texto simples: Formatos básicos de texto.
Nota Importante: O formato CSV não é considerado adequado para representar documentos complexos, pois não suporta nativamente a estrutura hierárquica necessária para dados aninhados.
3. Operações em MongoDB (MQL - MongoDB Query Language)
O MongoDB é um dos SGBDs orientados a documentos mais utilizados, destacado por sua velocidade na manipulação de petabytes de dados e suporte a ambientes distribuídos.
Gerenciamento de Banco e Coleções
· Listar bancos: show dbs
· Selecionar/Criar contexto de banco: use nome_do_banco (O banco só é efetivamente gravado após a inclusão do primeiro dado).
· Criar Coleção: 
db.createCollection("pedidos", {capped:true, size:1310720, max:500})
· Capped: Define se a coleção tem tamanho limitado.
· Size: Tamanho máximo em bytes.
· Max: Número máximo de documentos permitidos.
· Listar coleções: show collections
Manipulação de Dados (CRUD)
· Inserção Simples:
· Inserção de Múltiplos Documentos: Utiliza-se colchetes [] para passar uma lista de objetos ao comando .insert().
· Consulta Total: db.pedidos.find() (Opcionalmente, pode-se usar .pretty() para formatar a saída de forma indentada).
· Exclusão de Documentos: db.pedidos.remove({}) (Remove registros) ou db.pedidos.deleteOne({ "_id": ... }) (Remove um específico).
· Exclusão de Banco: db.dropDatabase()
Operadores de Comparação e Filtros
	Operador
	Expressão MongoDB
	Correspondente SQL
	Igual
	db.pedidos.find({ peso: { $eq: 10 } })
	where peso = 10
	Menor que
	db.pedidos.find({ peso: { $lt: 10 } })
	where peso 10
	Maior ou igual
	db.pedidos.find({ peso: { $gte: 10 } })
	where peso >= 10
	Diferente
	db.pedidos.find({ peso: { $ne: 10 } })
	where peso != 10
	Em uma lista
	db.pedidos.find({ qtd: { $in: [9, 15] } })
	where qtd in (9, 15)
Atualização de Dados
· updateOne: Altera o primeiro documento que coincide com o critério.
· updateMany: Altera todos os documentos que coincidem com o critério.
4. O Conceito de Agregado
O termo agregado refere-se a um conjunto de objetos relacionados que são tratados como uma unidade natural para facilitar o desenvolvimento e a escalabilidade em clusters.
· Vantagens: Melhora a replicação e a fragmentação (sharding) dos dados.
· Modelagem: Ao projetar para o modelo orientado a documentos, deve-se considerar quais dados são acessados juntos. Por exemplo, em vez de ter tabelas separadas para "Cliente", "Endereço" e "Pagamento", esses dados podem ser reunidos em um único agregado de "Cliente" ou "Pedido".
5. Implementação de Documentos no PostgreSQL (JSONB)
O PostgreSQL permite trabalhar com o modelo orientado a documentos usando o tipo JSONB. Isso possibilita unir a robustez do relacional com a flexibilidade do NoSQL.
Operadores JSONB no PostgreSQL
· ->: Recupera um campo ou elemento de array como um objeto JSON.
· ->>: Recupera um campo ou elemento de array como texto. (Útil para filtros em cláusulas WHERE).
· @>: Operador de contenção. Verifica se o documento JSON contém um determinado par chave-valor ou elemento.
· ?: Verifica se uma chave específica existe dentro do documento.
Funções e Recursos Especiais
· jsonb_pretty(coluna): Exibe o conteúdo JSON de forma organizada e indentada.
· jsonb_build_object(): Cria um objeto JSON a partir de uma lista de argumentos.
· CTE (Common Table Expressions): Utilizadas com a cláusula WITH, facilitam a organização de consultas complexas e recursivas sobre dados JSON, melhorando a legibilidade.
Exemplo de Consulta com Filtro em JSONB:
-- Busca filmes em que o campo 'generos' (um array) contém 'Ficção'
SELECT * FROM filmes WHERE dados->'generos' @> '["Ficção"]'::jsonb;
Índices em JSONB
A criação de índices do tipo GIN (Generalized Inverted Index) é uma vantagem significativa do JSONB sobre o JSON puro, pois acelera drasticamente as buscas por chaves e valores em grandes volumes de dados.
Exercícios
1. Assinale a afirmativa errada quando a relação entre a nomenclatura usada na definição de uma estrutura de um banco de dados orientado a documentos e um banco de dados relacional.
a) Banco de dados → banco de dados.
b) Linha → documento.
c) Tabela → coleção.
d) Registro → para chave-valor.
e) Tupla → documento.
2. Assinale a afirmativa que indica um formato dearquivo que não é usado para o armazenamento de dadosem umbanco de dados orientado a documentos:
a) BSON.
b) XLS.
c) XML.
d) JSON.
e) JSONB.
3. Assinale a afirmativa errada quanto ao entendimento do termo “agregado”em um projeto de banco de dados orientado a documentos:
a) Foi criado no surgimento do projeto orientado a domínios.
b) O agregado é um conjunto de objetos relacionados.
c) Facilita ainda o trabalho da implementação de software por parte dos desenvolvedores.
d) Na modelagem com agregados, os dados são definidos em unidades.
e) Seu uso é exclusivo para o modelo de dados relacional.
4. Assinale a afirmativa que indica um fator importante no projeto de um banco de dados orientado a documentos com a definição de agregados:
a) O número de agregados deve ser o mesmo da quantidade de tabelas existentes em um mesmo projeto no modelo relacional.
b) O máximo de agregações permitido é de três agregações.
c) Os agregados são criados para facilitar a execução das consultas.
d) O número de coleções é sempre superior ao número de tabelas de um projeto relacional.
e) O número de coleções é sempre igual ao número de tabelas de um projeto relacional.
Modelo de Dados NoSQL Baseado em Colunas (Apache Cassandra)
1. Introdução ao Modelo Colunar
O modelo baseado em colunas (ou colunares) é uma evolução dos modelos chave-valor e orientado a documentos. O Apache Cassandra destaca-se como o sistema gerenciador de banco de dados (SGBD) mais utilizado nesta categoria, sendo uma solução distribuída, descentralizada e de código aberto, ideal para lidar com volumes massivos de dados (Big Data).
Casos de Uso e Relevância
· Aplicações de Grande Escala: Utilizado por empresas como Apple (que gerencia cerca de 10 Petabytes em 75.000 nós), Facebook (criador da tecnologia), Instagram, Netflix, Spotify e Uber.
· Necessidade de Rapidez: Surgiu da demanda por acesso rápido e produção de respostas imediatas em ambientes de redes sociais e aplicações web de alto tráfego.
2. Características Principais do Apache Cassandra
O Cassandra foi projetado para evitar pontos únicos de falha e garantir alta disponibilidade. Suas principais características incluem:
· Descentralização: O banco é formado por um conjunto de nós onde os dados são replicados, garantindo que o sistema continue operando mesmo se parte da infraestrutura falhar.
· Escalabilidade Linear: O aumento da capacidade de processamento e armazenamento ocorre de forma proporcional ao acréscimo de novos nós ao cluster.
· Consultas Paralelas: A arquitetura permite a execução de consultas de forma simultânea entre os nós.
· Modelo de Dados Flexível: Ao contrário do modelo relacional, as colunas podem variar entre as linhas de uma mesma "tabela".
3. Comparação: Modelo Relacional vs. Modelo Colunar
A transição do modelo relacional para o colunar exige uma mudança de paradigma, especialmente no que diz respeito à integridade e à estrutura.
Equivalências de Terminologia
	Modelo Relacional
	Modelo Orientado a Colunas (Cassandra)
	Instância de Banco de Dados
	Cluster
	Database / Schema
	Keyspace (Contêiner/Agrupamento de dados)
	Tabela
	Família de Colunas (Column Family)
	Linha (Row)Linha (Coleção de colunas associadas por uma chave)
	Colunas fixas por linha
	Colunas podem ser diferentes entre as linhas
Diferenças Fundamentais
1. Relacionamentos: O modelo colunar não possui suporte para relacionamentos (chaves estrangeiras) nem garante integridade referencial.
2. Propriedades ACID vs. Teorema CAP: O Cassandra não utiliza transações ACID (Atomicidade, Consistência, Isolamento e Durabilidade). Em vez disso, baseia-se no Teorema CAP (Consistência, Disponibilidade e Tolerância a Particionamento).
3. Abordagem de Projeto:
· No Relacional: Projeta-se primeiro o banco (ER) e depois as consultas.
· No Colunar: O projeto é guiado pelas consultas. Identificam-se as necessidades da aplicação para criar tabelas que as atendam de forma eficiente, mesmo que isso resulte em redundância de dados.
4. Estrutura e Comandos de Definição (CQL)
A CQL (Cassandra Query Language) é a linguagem utilizada para manipular o banco. Embora sua sintaxe se assemelhe ao SQL, sua aplicação prática é distinta.
Gerenciamento de Keyspaces
O Keyspace é o nível mais alto de organização.
· Criação:
· Explicação: O replication_factor define quantas cópias dos dados serão mantidas.
· Uso e Verificação:
· Exclusão: DROP keyspace aula;
Tipos de Dados
O Cassandra oferece tipos nativos e permite a criação de tipos customizados:
· Básicos: text, varchar, int, bigint, float, double, boolean, uuid, timestamp.
· Especiais: timeuuid (variante de UUID para carimbo de tempo), blob (objetos binários), inet (endereços IP).
· Coleções: list (lista ordenada), map (pares chave-valor), set (conjunto de elementos únicos).
· Customizados: Criados via CREATE TYPE.
5. Modelagem de Tabelas e Chaves
Uma tabela (Família de Colunas) no Cassandra é definida pela sua Chave Primária, que possui um papel crítico na distribuição dos dados.
Componentes da Chave Primária
1. Chave de Partição (Partition Key): Responsável por distribuir os dados uniformemente pelos nós do cluster.
· Regra de Ouro: Uma partição não deve ultrapassar 100 MB, sendo o ideal manter-se abaixo de 10 MB.
2. Chave de Armazenamento em Cluster (Clustering Columns): Opcional, usada para organizar e ordenar os dados dentro de uma partição.
Exemplo de Tabela de Log:
CREATE TABLE log (
 filial varchar,
 data timestamp,
 datahora timeuuid,
 login varchar,
 PRIMARY KEY ((filial, data), datahora));
· Neste exemplo, (filial, data) formam a chave de partição composta, e datahora é a coluna de agrupamento (clustering).
6. Manipulação e Consulta de Dados (DML)
Inserção e Atualização
· INSERT: Inclui registros. O comando IF NOT EXISTS pode ser usado para evitar sobreposição indesejada.
· UPDATE: Atualiza campos específicos. No Cassandra, o UPDATE e o INSERT funcionam de forma similar (se o registro não existir no update, ele pode ser criado, dependendo da configuração).
Deleção
Para deletar dados, é necessário informar a Chave Primária completa ou a Chave de Partição. O Cassandra não suporta o operador OR em comandos de exclusão.
· Exemplo Correto: 
DELETE FROM log WHERE filial = 'filial_1' AND data = '2020-11-17';
Consultas (SELECT) e Filtros
Consultas em colunas que não fazem parte da chave primária geram erro, a menos que um Índice Secundário seja criado.
· Criação de Índice: 
CREATE INDEX ON usuario (nome);
· Cláusula ALLOW FILTERING: Necessária para consultas de agregação (como COUNT) que podem impactar a performance.
7. Limitações da Linguagem CQL
Para manter a alta performance e eficiência, a CQL impõe restrições severas:
· Sem Joins: Não é possível realizar junções entre tabelas.
· Operadores Restritos: Não há suporte nativo para o comparador OR ou consultas em partes de cadeias de caracteres (como o LIKE parcial do SQL).
· Agrupamentos: Não há suporte para GROUP BY tradicional da mesma forma que no SQL.
· Filtros: Campos comuns só podem ser filtrados se houver índice secundário ou uso de ALLOW FILTERING.
· Comparadores: Operadores de maior (>) ou menor () ;
INSERT INTO pedido ( nrpedido, livro, autor)
VALUES ( uuid(), 'NOSQL Essencial', { 'Pramod J. Sadalage', 'MartinFowler'});
a) É criada uma tabela no um identificar universal e o valor gerado pela função uuid().
b) Há um atributo do tipo set, mas não pode ser criado no Cassandra.
c) O insert apresenta o cadastro dos nomes de dois autores.
d) A tabela foi criada, mas também poderia ser definida como uma COLUMNFAMILY.
e) O uso do tipo de dado uuid em uma chave primária é indicado por ser único.
4. Sobre o código apresentado a seguir, podemos afirmar, exceto:
CREATE TABLE log_usuario (
login varchar ,
data timestamp ,
datahora timeuuid ,
PRIMARY KEY ( ( login , data ), datahora ) ) ;
INSERT INTO log_usuario ( login, data, datahora ) VALUES ( 'aluno_1', toTimestamp(toDate(now())), now() ) ;
INSERT INTO log_usuario ( login, data, datahora ) VALUES ( 'aluno_2', toTimestamp(toDate(now())), now() ) ;
INSERT INTO log_usuario ( login, data, datahora ) VALUES ( 'aluno_3', toTimestamp(toDate(now())), now() ) ;
a) Existe uma chave primária tripla.
b) A função toTimestamp(toDate(now())) permite obter o valor timestamp.
c) A função now() permite o preenchimento do atributo timeuuid.
d) A tabela tem dois atributos no campo chave de partição.
e) A tabela tem o campo datahora como chave de armazenamento em clusters.
5. Assinale a afirmativa correta sobre como a consulta abaixo pode ser executada no Cassandra:
SELECT * FROM usuario WHERE nome = 'Lia' ;
a) Não pode usar o *, como na SQL precisa da indicação dos atributos a serem exibidos.
b) Não pode ser executada, pois o banco trabalha apenas com o IN.
c) Necessita da criação de um índice secundário no campo nome.
d) Pode ser executada sem necessidade de qualquer recurso extra.
e) Só pode ser executada se o atributo nome fizer parte da chave de partição.
6. Considerando a necessidade de uma consulta para a contagem de registros, com o uso da função count(), de acordo com uma determinada condição, ela pode ser realizada no Cassandra desde que:
a) Não pode ser realizada, pois o Cassandra não tem agregações.
b) Pode ser executada sem nenhum recurso extra.
c) Pode ser executada com o uso de um índice secundário.
d) Uma permissão seja incluída no fim da consultacom um allow filtering.
e) Pode ser executada com o uso de um índice primário.
Modelo de Dados NoSQL Baseado em Grafos e Linguagem Cypher
O modelo de banco de dados baseado em grafos é uma solução NoSQL projetada para lidar com aplicações que manipulam grandes volumes de dados altamente conectados. Diferente do modelo relacional, onde múltiplos relacionamentos entre tabelas podem tornar as consultas complexas e lentas (devido a operações de junção dispendiosas), o modelo de grafos foca na eficiência das conexões entre as entidades.
1. Fundamentos do Modelo de Grafos
Um banco de dados de grafos é composto por dois elementos principais que definem sua estrutura: vértices (nós) e arestas (relacionamentos).
Vértices (ou Nós):
Os nós representam as entidades do domínio, de forma semelhante ao conceito de tabelas ou registros no modelo relacional.
· Exemplos: Pessoas, Lugares, Empresas, Tecnologias.
· Identificação: Para facilitar a visualização, os nós costumam ser representados por cores diferentes para cada tipo de entidade.
· Atributos: Cada nó pode conter qualquer número de propriedades, armazenadas como pares de chave-valor (ex: nome: "Ana", email: "ana@email.com").
Arestas (ou Relacionamentos)
As arestas são as conexões entre os nós e traduzem a semântica da ligação.
· Semântica: Cada relacionamento deve ser nomeado para explicar o vínculo (ex: uma pessoa trabalha_para uma empresa ou tem_interesse em uma tecnologia).
· Direcionalidade: Os relacionamentos possuem direção, tipo e pontos iniciais e finais definidos.
· Propriedades em Arestas: Assim como os nós, as arestas também podem ter propriedades. Elas podem indicar valores temporais, pesos, distâncias ou classificações (ex: um relacionamento trabalha_com pode ter a propriedade desde: 2015).
Propriedades
São pares de valores-chave onde os dados reais são armazenados. Elas podem ser comparadas aos atributos do modelo relacional.
2. Características e Vantagens
O modelo de grafos destaca-se pela sua flexibilidade e performance em cenários específicos:
· Performance Nativa: O acesso aos nós e relacionamentos permite percorrer milhares de conexões por segundo, independentemente do volume total de dados, utilizando o poder da computação distribuída.
· Navegação Eficiente: Diferente dos SGBDs relacionais, que sofrem com junções (joins) custosas em tempo de execução, os grafos permitem navegar pelas conexões de modo eficiente em qualquer direção.
· Esquema Flexível: Bancos de dados como o Neo4j não exigem o uso de um esquema rígido (schema-less), facilitando a evolução do modelo conforme a necessidade da aplicação.
· Escalonamento: Possui processos de escalonamento facilitados pela estrutura fundamental baseada em propriedades nos relacionamentos.
Limitações
· Auto-relacionamento: Em certas modelagens de grafos, um nó não tem a possibilidade de criar um relacionamento consigo mesmo.
· Hierarquia: Em termos de hierarquia rígida, um nó não pode ser seu próprio pai, apesar de poder ser o pai de outros nós.
3. Aplicações Indicadas
Os bancos de dados de grafos são ideais para aplicações onde o relacionamento entre os dados é tão importante quanto os dados em si.
	Categoria
	Exemplos de Uso
	Redes Sociais
	Mapear usuários (nós) e suas amizades ou seguidores (arestas).
	Sistemas de Recomendação
	Analisar círculos de amizade e interesses comuns para sugerir produtos.
	Telecomunicações
	Modelar redes de computadores de provedores de serviços.
	Ciência e Técnica
	Mapeamento de campos de petróleo em tempo real; pesquisa de padrões genéticos e interações de proteínas.
	Análise de Dados Complexos
	Cruzamento de dados distintos para analisar possibilidades de uso e tendências de mercado.
 
4. O SGBD Neo4j
O Neo4j é o sistema gerenciador de banco de dados (SGBD) mais utilizado entre os que seguem o modelo de grafos. Lançado em 2007, ele possui as seguintes características técnicas:
· Código Aberto: Possui licença pública GNU e interface gráfica rica.
· Conformidade ACID: Suporta transações com Atomicidade, Consistência, Isolamento e Durabilidade.
· Alta Disponibilidade: Possui recursos para uso em clusters.
· Gerenciamento de Backups:
· Backup Frio: Realizado quando o banco de dados não está em execução.
· Backup Quente: Realizado com o banco de dados em pleno funcionamento.
5. Linguagem Cypher: Manipulação e Consulta
A Cypher é a linguagem declarativa do Neo4j, inspirada no SQL, mas projetada para representar padrões de nós e arestas de forma legível.
Comandos de Definição e Inserção (CRUD)
· CREATE: Usado para criar nós e relacionamentos.
· Exemplo de criação de nó: 
CREATE (p:Pessoa {nome: 'Ana', email: 'ana@meumail.com'})
· Exemplo de criação de relacionamento: 
CREATE (p1)-[:AMIGO]->(p2)
· MERGE: Funciona como um comando de "garantia", criando o dado apenas se ele ainda não existir.
· MATCH: Localiza dados no grafo (semelhante ao SELECT ou WHERE).
· DELETE: Remove nós ou relacionamentos. É necessário localizar o nó com MATCH antes de deletar.
· Exemplo: 
MATCH (n:Funcionario {nome: 'Rui'}) DELETE n
Comandos de Atualização
· SET: Altera o valor de uma propriedade existente ou adiciona uma nova.
· Alteração simples: 
MATCH (p:Funcionario {nome: 'Lia'}) SET p.salario = 4500.00
· Adição de propriedade (operador +=): 
MATCH (p:Funcionario {nome: 'Lia'}) SET p += {email: 'lia@empresa.com.br'}
· Remoção de propriedade: Atribuir valor null à propriedade (ex: SET p.email = null).
Consultas e Filtros
As consultas podem retornar nós inteiros ou propriedades específicas.
· Retorno de propriedades: 
MATCH (p:Funcionario) RETURN p.nome, p.salario
· Ordenação: 
MATCH (n) RETURN n.nome ORDER BY n.nome
· Filtros Complexos (WHERE):
· Intervalos: WHERE 4000para o tratamento de aplicações complexas.
d) Como exemplos de aplicações indicadas para serem desenvolvidas com esse modelo de dados podem ser listadas as aplicações para o gerenciamento de dados geográficos ou para modelar redes de computadores de um provedor de telecomunicações.
e) O banco de dados em grafo é indicado para aplicações que têm no cruzamento de dados distintos uma possibilidade de melhor análise.
3. Assinale a afirmativa que contém o comando correto para listar todos os dados das Pessoas cujo nome está contido em Ana ou Lia:
a) MATCH [ p : Pessoa ] WHERE p.nome IN [ 'Ana', 'Lia' ] RETURN p
b) MATCH ( p : Pessoa ) WHERE p.nome IN [ 'Ana', 'Lia' ] RETURN p
c) MATCH ( p : Pessoa ) WHERE p.nome IN ( 'Ana', 'Lia' ) RETURN p
d) SELECT ( p : Pessoa ) WHERE p.nome IN [ 'Ana', 'Lia' ] RETURN p
e) MATCH ( p : Pessoa ) WHERE p.nome = 'Ana' and p.nome = 'Lia' RETURN p
2