Banco de Dados NOSQL

Prévia do material em texto

Banco de Dados NOSQL
bancos de dados NoSQL no qual são não-relacionais, com seu surgimento por meados de 2009 para suprir a necessidade do processamento de Big Data. Partindo de uma ideia open source de ferramentas para armazenamento.
Aula 1 (RESUMO): Nesta aula, iniciaremos o estudo de Banco de Dados NOSQL, que é uma das áreas mais recentes em banco de dados. Porém, será necessário antes compreendermos a evolução dos modelos de dados para identificarmos as razões da criação desses novos modelos. Após isso, compreenderemos as principais características dos modelos Not Only SQL. Efetuaremos a comparação com o BD relacional e suas diferenças para os modelos NOSQL.
Objetivos:
- Analisar a evolução dos modelos de BD;
- Reconhecer os tipos de dados: estruturados, semiestruturados e não- estruturados.
- Reconhecer as diferenças do BD relacional para os modelos NOSQL.
Introdução:
 A área de BD é uma das mais antigas na computação e sua evolução foi marcada pelos diferentes modelos de dados que foram sendo criadas ao longo do tempo. Um modelo de dado é a forma como os dados são organizados no banco.
PRIMEIROS MODELOS DE DADOS:
Os primeiros modelos de dados foram o modelo hierárquico e o modelo em rede;
Modelo em rede:
Era organizado com o seu conjunto de registros interligados por meio de ponteiros. As dificuldades encontradas tanto em nível de projeto quanto em relação ao seu uso e suas limitações, provocaram a busca por outros modelos de dados.
Modelo hierárquico: 
Era estruturado de modo que era permitido o desenvolvimento de relacionamentos do tipo pai-filho entre as tabelas, apresentando a exigência que todo o projeto de banco de dados necessitava ser definido de forma hierárquica.
Em 1970 surge então um modelo de dados que ainda é amplamente usado, representando aproximadamente 70% do mercado atual (https://db-engines.com/en/ranking_categories). Veja a seguir.
MODELO RELACIONAL:
O modelo relacional surgiu com o objetivo principal de superar questões relacionadas com o suporte (manutenção facilitada em relação aos seus antecessores), a independência e a integridade dos dados nos Sistemas Gerenciadores de Banco de Dados (SGBD) (Elmasri, 2015). No período em que foi lançado, operações comuns envolvendo consultas apresentavam problemas por falta de integridade de dados e, para solucionar isso era necessário o desenvolvimento de programas complexos. 
FATORES DE SUCESSO NOS MODELOS DO MODELO RELACIONAL:
1- Houve uma boa aceitação dos usuários e da comunidade acadêmica ao modelo relacional devido a sua simplicidade e uniformidade com um conjunto de tabelas utilizando atributos atômicos; seu formalismo matemático baseado na álgebra e calculo relacional, além da teoria dos conjuntos e o uso de uma linguagem padronizada (SQL – Structured Query Language).
2- Além disso, o controle de transações disponíveis por meio das propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) permitiu um maior controle de suas operações. Cabe destacar, também, a característica da primeira forma normal, a qual estabelece que atributos armazenados em uma tabela devem ser simples, não podendo ser multivalorados ou compostos, sendo essa uma diferença marcante para os modelos NoSQL (Fowler, 2013).
3- Para completar a lista de principais fatores de sucesso do modelo relacional, o modelo Entidade-Relacionamento criado em 1976 facilitou bastante o projeto de modelo de dados, assim como o entendimento da estrutura do banco de dados relacional, exibindo o esquema (conjunto de tabelas relacionadas em uma aplicação) de forma gráfica e facilitando a construção de consultas envolvendo várias tabelas (joins).
Os SGBDs relacionais disputam espaço na indústria de Banco de Dados com outros SGBDs não relacionais, tais como o SGBD Orientado a Objeto e os NOSQL (Not Only SQL). Diante do avanço da Orientação a Objetos (OO), os grandes fabricantes de SGBDs decidiram acrescentar recursos presentes na tecnologia OO e seus SGBDs relacionais, denominando-os como Relacionais-objeto (SGBDRO), ou universais.
Em relação as características dos SGBD’S relacionais – objeto, podem ser listados a possibilidade de criação de outros tipos de dados ampliando a lista de tipos primitivos de dados pré existentes nos SGBD’S e o suporte ao principio da herança entre objetos no contexto SQL, entre outros.
TIPOS DE DADOS: 
Com o avanço da computação e suas aplicações, surgiram outras necessidades de uso de banco de dados quanto aos novos formatos de dados. Tais aplicações foram caracterizadas pelo aumento da complexidade e necessidade de maior velocidade no processamento das consultas.
Exemplo:
Como exemplos de aplicações, podem ser mencionados projetos na área de genética; analise de dados e padrões de consumo, redes sociais e big data. Vale destacar, também, o crescimento massivo dos dispositivos móveis, em particular os smartfones, que possibilitaram a muitos usuários produzir e consumir dados não – estruturados. 
Outra justificativa para a criação de bd baseados em outros modelos de dados surgiu do fato de que novas aplicações passaram a necessitar de outros tipos de dados, além do formato pré estabelecido e fixo que é usado nos bancos de dados relacionais. Um bom exercício mental para entender essa necessidade é o de imaginar como uma rede social projetada usando um conjunto de tabelas no modelo relacional. Em termos de classificação, podemos classificar os tipos de dados em estruturados, semi- estruturados e não estruturados.
Dados estruturados:
A estrutura é definida antes da carga de dados e segue essa estrutura de forma fixa, não importando se o atributo será ou não preenchido. O exemplo clássico de dados estruturados é a tabela no bd relacional. Na tentativa de estabelecimento de padrões estruturais para pré-definir o conjunto de campo das tabelas, diversos metadados foram estabelecidos. No caso de documento na web, um metadado foi criado com o objetivo de estabelecimento de um formato para os dados da web, que é o padrão DUBLIN CORE que visa descrever o formato de objetos digitais, tais como, vídeos, sons, imagens, textos na web.
Para termos uma noção da dificuldade de estabelecimento de um padrão, o Dublin Core tem 15 elementos básicos que são: 
1. Title: o titulo será o nome pelo qual o recurso é conhecido;
2. Creator: o autor que pode ser uma pessoa, uma organização ou serviço;
3. Subject: o assunto que será expresso com o uso de palavras-chave;
4. Description: a descrição que será realizada incluindo tabelas, referencias ou um texto livre;
5. Publisher: o publicador é uma pessoa, uma organização ou um serviço;
6. Contributor: o contribuídor é uma pessoa, uma organização ou serviço que auxiliou na publicação do documento;
7. Date: data da criação ou disponibilização do documento, sendo recomendado o uso do formato AAAA-MMADD.
8. Type: com o descritor tipo do recurso é possível descrever a categoria mais adequada do recurso;
9. Format: o formato pode incluir o tipo da mídia usada ou o tamanho ou as dimensões do recurso. É usado também para indicar o software, hardware ou outro equipamento necessário para apresentar ou manipular o recurso;
10. Identifier: recomenda-se usar uma chave única conforma um sistema de identificação formal, como, por exemplo, uniform resourse identificador - uri, entre outros.
11. Sourse: identifica a fonte do recurso que pode ser oriunda apenas de uma fonte ou de múltiplas fontes;
12. Language: esse descritor apresenta o código do idioma usado no recurso, com 2 letras;
13. Relation: a relação indica se o recurso tem algum tipo de relacionamento com outro recurso;
14. Coverage: esse importante descritor é usado para indicar a abrangência ou cobertura do recurso, incluindo a localização espacial, período temporal, ou jurisdição aplicada;
15. Rights: é o descritor que indica regras relativas aos direitos autorais ou copyrights.
A falta de flexibilidade do modelo relacional provoca a definição, em algumas situações, de tabelas com muitos atributos, considerando todas as possibilidades de dados a seremcadastrados no banco, como por exemplo, um atributo para o cadastro do numero do bloco de um endereço de apartamento, mesmo com o conhecimento que nem todos os prédios possuem tal divisão.
Dados semiestruturados:
Os dados são irregulares, incompletos não é necessário seguir um esquema pré definido. Em relação aos dados irregulares, os livros podem ser exemplos, pois eles são descritos por uma estrutura usando capítulos e seções ou podem ser descritos usando apenas capítulos; outro exemplo seria a descrição de uma disciplina em uma universidade que podem variar em termos de seus atributos e tópicos de um departamento para outro, onde em um departamento faltam atributos e em outro existem atributos a mais.
Com a variação da estrutura e o avanço da web, a linguagem de marcação HTML, que é de natureza estática, se mostrou inadequada para atender essa variação. Na tentativa de solução, foi definida a linguagem de marcação extensível XML, ampliando o uso dessa categoria de dados. Com a XML, foi possível realizar o intercambio de dados armazenado nos bd’s e diminuir o problema da pré definição da estrutura do arquivo, tendo em vista que permite que as aplicações apresentem os dados com mais flexibilidade, com o usuário definindo suas próprias tags para o uso na estrutura do arquivo.
Quando os dados são incompletos, nem todos os atributos são preenchidos, apesar do campo ter sido criado na tabela. Um primeiro exemplo desse caso é que nem todos os livros tem apêndice ou prefacio. Outro bom exemplo é o arquivo no formato de referência bibliográfica BIBTEX, que tem uma estrutura para descrição de documentos, porém, como essa estrutura varia de acordo com a obra descrita, nem todos os campos são usados. Outro exemplo, que usa dados semiestruturados são os formatos permitidos para as amostras de experimentos do national center for biotechnology information – NCBI, que utiliza o formato .XML para disponibilizar arquivos de testes de RNA (ácido ribonucleico). 
Exemplo: 
Outro exemplo sobre os dados semiestruturados são as paginas web contendo dados sobre documentos em estruturas variadas. Essa característica facilitou a apresentação de dados armazenados em banco de dados na web, possibilitando a independência de armazenamento e permitindo a visualização de dados oriundos de fontes heterogêneas (diferentes sgbds), alcançando assim uma independência de apresentação.
DADOS NÃO ESTRUTURADOS:
Esses não podem ser descritos como em tabelas pré definidas em termos de estrutura. Estão incluídos neste grupo, dados como comentários em redes sociais, arquivos de vídeo e de áudio, imagens em seus diversos formatos, mensagens publicadas em redes sociais, arquivos de testos diversos, mensagens instantâneas de aplicativos, relatórios distintos dos exportados em consulta em bd, mensagem de e-mail, entre outros. Esse tipo de dado representa mais de 80% dos dados atuais usados no mundo e seu volume continua em franco crescimento, o que pode ser comprovado pela quantidade de empresas que foram criadas nos últimos anos.
 BANCO DE DADOS NOSQL:
Tendo em vista as características dos tipos de dados apresentados anteriormente, houve a necessidade de pesquisa para o desenvolvimento de modelos de dados mais adequados para uso com as aplicações mais recentes, como é o caso das redes sociais por exemplo. Para melhor atendermos as vantagens no uso desse modelo de dados, vamos compara-lo ao modelo relacional. A comparação será realizada em relação as seguintes características: 
-Linguagem de manipulação;
A característica principal dos modelos NoSQL é que as operações de criação e gerenciamento dos dados não estão limitadas a serem executadas apenas com a linguagem de consulta estruturada (SQL). Nesses modelos, a SQL não é usada como a única linguagem de consulta. A tecnologia é na verdade um conjunto de tecnologias que facilitam a resolução dos problemas para uma ampla variedade de aplicações que não são indicadas para uso no modelo relacional. Em termos de linguagem, há inclusive outras linguagens que podem ser usadas, como a UnQL(Unstructured Query Language), ou simplesmente UnQL (pronunciada como “Uncle”), que é usada em SGBDs como o Couchbase. A sintaxe da linguagem tem variação entre SGBDs e por modelos de dados NoSQL, com a existência de linguagens específicas como o caso da linguagem Cypher usada pelo Neo4J, que é um SGBD baseado em grafos e que será ainda estudado na disciplina.
- Estrutura utilizada nos modelos NoSQL;
Quando comparamos os modelos de dados NoSQL e relacional observamos esta diferença: os bancos de dados relacionais usam um esquema pré-definido (fixo) para estruturar suas tabelas, enquanto os bancos de dados NoSQL possuem um esquema dinâmico. Esse tipo de esquema permite que o banco de dados armazene registros que não tenham o mesmo conjunto de atributos. Os bancos de dados relacionais têm em sua estrutura apenas tabelas ou relações, porém, no caso dos bancos de dados NoSQL, são usadas quatro estruturas que foram definidas para atender a diferentes demandas surgidas dos diversos formatos de dados mais recentes. Assim, podem ser usados modelos baseados em documentos; coleções de pares chave-valor; armazenamento orientado em colunas; e modelo baseado em grafos.
- Poder de execução de consultas complexas;
Ainda sobre as principais diferenças entre os modelos, o relacional é mais adequado para o ambiente em que são necessárias consultas complexas, enquanto os NoSQL não, pois normalmente contêm um conjunto de atributos para a publicação de uma base de dados. O relacional tem um poder maior na definição de consultas pois, normalmente, há a presença de muitas tabelas em uma aplicação relacional e com o cruzamento de dados pode-se aumentar as possibilidades advindas das junções, que podem ser criadas nas respostas às consultas.
- Desempenho;
Além disso, um banco de dados relacional pode apresentar dificuldades para a execução de consultas em grandes volumes de dados com alto desempenho, entre outras razões por conta da necessidade das junções que são realizadas. Por esse motivo, os modelos NoSQL também foram projetados para o armazenamento de dados em bancos distribuídos e, dessa forma, são muito indicados ao uso em aplicações com grandes volumes de dados, do tipo Big Data. Os bancos de dados relacionais não têm um ajuste para permitir o crescimento do processamento de forma a atender o aumento do volume de dados. Há a necessidade de ajustes na configuração do SGBD, o que nem sempre é trivial de ser realizado. Com o volume de dados aumentando consideravelmente devido ao crescimento do uso da web (redes sociais em particular), a necessidade de uma solução para permitir o controle do gerenciamento desse volume de dados se tornou urgente.
-Escalonamento;
Escalonamento Existem dois tipos de escalonamento de servidores: o vertical, no qual há um aumento (upgrade) no servidor (scale up) para a busca de uma maior capacidade de processamento; e o escalonamento horizontal, em que ocorre um aumento do número de servidores (scale out), buscando paralelismo. A primeira ideia de solução para aumentar o poder de processamento dos SGBDs relacionais foi o escalonamento vertical. Porém, mesmo assim, a conclusão foi que o volume de dados continuaria a ser um fator limitador, com impacto direto no desempenho do sistema. Considerou-se o uso da distribuição dos dados em vários nós (servidores de bancos de dados), ideia que tem como consequência a implementação de ajustes para a utilização no processamento de consultas, assim como no projeto de banco de dados distribuídos.
Os bancos de dados NoSQL possuem escalonamento horizontal e, com isso, podem ter um aumento na capacidade de processamento. A distribuição do banco de dados em várias máquinas é feita pelo particionamento dos dados. O processo é também conhecido como sharding. O processo de sharding objetiva trabalhar com o escalonamento horizontal, paralelizando seus dados em vários servidores. O próprio volume dos dados por máquina é em muito minimizado como consequência do processo de distribuição.Conjuntos de dados de tamanho menor são mais fáceis de serem acessados, atualizados e gerenciados;
- Controle transacional.
m aplicações que necessitam de alta capacidade de operações transacionais, os bancos de dados relacionais são os mais adequados, pois têm um controle mais rígido sobre essas operações. Isso se deve ao fato de seguirem as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). Uma transação consiste em uma unidade de trabalho ou bloco de comandos que tem um significado lógico no sistema de banco de dados, como uma operação bancária, por exemplo. Já os bancos de dados NoSQL são baseados no Teorema CAP (Consistência, Disponibilidade e tolerância à Partição).
Diferenças para o relacional:
Não há apenas um modelo de dados:
· Chave-valor;
· Orientado a documentos;
· Colunar:
· Grafos.
Não está limitado a SQL:
· Mongo DB;
· Cassandra Query;
· Language;
· Cypher;
Controle transacional:
· Propriedades ACID (Atomicidade, Consistência, Isolamento e durabilidade);
· Teorema CAP (Consistência, Disponibilidade e Partição).
Schemalles:
· Sem exigência previa de formato da estrutura.
Aula 2 (RESUMO): Modelos de BD NoSQL
Banco de Dados: Chave-valor.
Os bancos de dados no modelo chave-valor são bem mais fáceis de serem particionados e possibilitam a escalabilidade do tipo horizontal, algo que outros modelos de dados não oferecem. Assim, dependendo do volume dos dados das aplicações, os administradores de bancos de dados (DBA), juntamente com a equipe responsável pela arquitetura da aplicação, podem sugerir o particionamento desses dados, assim como sua replicação com clusters para obter maior escalabilidade e disponibilidade, eliminando assim o perigo de ter um ponto único de falha no sistema e aumentando a performance.
Características do banco de dados baseado em chave-valor
1De modo a detalhar como os dados são armazenados, a chave pode ser usada de diversas formas, mas isso depende do SGBD, que pode impor algumas limitações. Por motivos de desempenho, deve-se evitar o uso de uma chave muito longa. A chave deve seguir uma padronização para permitir a administração, assegurar a qualidade dos dados e manter a consistência. Os valores armazenados também podem ser uma lista ou ainda um outro par chave-valor encapsulado em outro objeto.
2Ainda em relação ao valor armazenado, dentro de um campo de uma tabela no banco de dados chave-valor, pode-se armazenar tipos de dados diferentes para as chaves. Cabe ao DBA verificar as funcionalidades do SGBD que utilizará na aplicação, pois alguns SGBDs que usam o modelo de armazenamento baseado em chaves permitem a definição do tipo de dados para o valor, por exemplo, pode-se determinar que o valor deve ser um atributo inteiro ou um texto. Porém, outros bancos de dados não oferecem essa funcionalidade e, nessa situação, o valor armazenado pode ser de qualquer tipo de dado.
3Por conta de sua simplicidade, os SGBDs chave-valor são muito usados em aplicações que necessitam de velocidade nas pesquisas. Eles têm um desempenho superior aos relacionais, principalmente quando são usados em operações que necessitam de velocidade nas leituras e gravações de dados. Isso devido ao fato de que seu suporte ao processamento não segue o modelo clássico de transações usado nos bancos relacionais com base nas propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade) (ELMASRI, 2018). Ou seja, a velocidade foi o critério primordial para a indicação dos tipos de aplicações mais adequadas para seu uso, assim como suas formas de armazenamento de dados, com um suporte de transações diferente dos relacionais.
Assim, pode-se dizer que esse modelo de dados é muito eficaz quanto ao dimensionamento de acordo com as aplicações que operam com dados não transacionais de alta velocidade. Por não oferecer suporte transacional, exigem dos desenvolvedores das aplicações a codificação para o tratamento dos dados, a replicação e as rotinas de tolerância a falhas, tendo em vista que não são expressamente controlados pela própria tecnologia usada no modelo de dados. Por outro lado, essa escolha facilita o uso do modelo em aplicações web e dispositivos móveis, ou ainda em aplicações com a inclusão automática de dados.
- é o modelo mais simples de todos;
-Permite o armazenamento de dados sem esquema;
-Assim como a maioria dos bd NoSQL foram criados visando os ambientes web: ex; ao fazer login em um site, os usuários desejam que seu perfil seja carregado o mais rápido possível.
- A partir do armazenamento chave-valor é possível: 
· Obter o valor a partir de uma chave;
· Inserir o valor para uma chave;
· Apagar uma chave e seu respectivo valor;
- Por fazer o acesso pela chave primária, há um ótimo desempenho e podem ser facilmente escaláveis;
- Todos os armazenamentos podem ser consultados pela chave 
- Não é possível fazer pesquisas utilizando algum atributo da coluna de valores;
A forma de consulta torna o chave-valor muito indicado para armazenar dados de sessão (ID da sessão como chave);
· Dados de carrinho, perfis de usuário são boas possibilidades de uso.
-Os bancos também permitem expirar chaves com o tempo, ex:
· Carrinhos de compras não concluídos.
ONDE UTILIZAR CHAVE-VALOR?
ARMAZENAMENTO DE INFORMAÇÃO DE SESSÃO
- Como toda sessão é única e recebe um sessionid, o armazenamento chave-valor é indicado nesse caso;
- Tudo da sessão pode ser armazenado em valor e recuperado facilmente a partir do ID da sessão; 
- Existem diversos bd NoSQL chave-valor usados nessa aplicação.
PERFIS DE USUSARIOS, PREFERENCIAS:
- Normalmente perfis de usuário possuem algum atributo único: ID, Username...
- Os usuários web também podem ter um conjunto de preferencias: idioma, cor de fundo, fuso horário...
- Tudo isso pode ser colocado em um único agregado e acessado através da chave do usuário. Perfis de produto também podem ser armazenados!
DADOS DE CARRINHO DE COMPRA:
- Um dos primeiros bancos dessa natureza foi desenvolvida pela amazon (porque será, né?)
- Como queremos carrinhos sempre disponíveis, todas as informações de carrinhos podem ser colocadas em valor e a sua chave será a ID do usuário.
ONDE NÃO USAR: muitos relacionamentos entre dados
- Quando há muitos relacionamentos entre os dados ou for necessário relacionar dados de múltiplas chaves os bancos de dados chave-valor não são uma boa opção;
- Alguns fornecem recursos para navegação entre conexões, mas mesmo assim não são muito eficientes.
Transações com múltiplas operações:
- Se o sistema estiver salvando múltiplas chaves e ocorrer uma falha na gravação de uma delas e você quiser reverter ou desfazer o restante, chave- valor não ajuda nessa situação.
- mais indicado em operações mais simples.
CONSULTA POR DADOS:
- BD chave-valor permite a pesquisa por chaves, se o seu interesse está em parte dos pares chave -valor esse tipo de banco não é indicado;
Ex: quantas pessoas tem o nome de LUANA, ele não funcionará, pois ele não busca pelas (palavras chave) mas sim por valores (objetos, características, preferencias). Por isso para consultas mais refinadas ele não terá serventia.
OPERAÇÕES POR CONJUNTOS:
- As operações são limitadas a uma chave por vez;
- Não há como trabalhar em múltiplas chaves ao mesmo tempo.
SITES QUE UTILIZAM ESSE BD:
-StackOverflow;
- Flickr;
-Tumblr;
-Github;
-Instagram;
-Twiter;
-Vine;
-Alibaba.
BD QUE UTILIZAM CHAVE-VALOR:
· Berkeley DB
· Tokyo cabinet
· Kyoto cabinet
· Project valdermort
· memcacheDB
· SimpleBD
· Redis
· Riak
· hamsterDB
· amazondynamodb (não é open source)
BANCO DE DADOS ORIENTADO A COLUNAS:
1. Apesar de semelhante a uma tabela de modelo relacional, precisamos deixar de lado um pouco este conceito.
2. Nos bancos relacionais, são definidas as tabelas com suas colunas e tipos e a aplicação insere as linhas.
3. Já nesse modelo são definidas as famílias de colunas e podem ser definidos metadados sobre as mesmas. Mas as colunas são determinadas pela aplicação cliente.
4. São utilizadas chaves de linha que associa múltiplas colunas.
5. Os bds relacionais usam linhas com unidade de armazenamento6. Quando as atualizações são raras e as leituras de certas colunas são frequentes o armazenamento em colunas é mais indicado.
7. Os bancos organizam suas colunas em famílias
8. Cada coluna faz parte de uma única família de colunas 
9. As colunas de uma família são normalmente acessadas juntas.
10. São semelhantes as tabelas, a diferença é que não é obrigatório haver dados para todas as colunas definidas. (só aparece os valores que foram preenchidos e não tem obrigatoriedade de ser completa)
11. Não são totalmente sem esquemas, as famílias são projetadas para possuir um tipo de dado. 
12. Uma linha é uma coleção de colunas anexadas ou associadas por uma chave;
13. Uma coleção de linhas semelhantes constitui uma família.
RECURSOS DE CONSULTA:
· Devemos modelar para acesso aos dados;
· O mais usado é o Cassandra;
· À medida que os dados são inseridos nas famílias, os dados das linhas são ordenados por nomes de colunas;
- Se uma coluna é recuperada com maior frequência, é melhor utilizar esse valor para chave de linha.
· No Cassandra as consultas incluem GET, SET E DEL;
· Podemos ler dados de toda família ou de uma coluna especifica;
· Para atualizar dados utilizamos o comando SET na coluna que terá seu valor alterado.
· Para excluir usa-se o DEL, também é possível excluir uma coluna ou uma família inteira.
· Alguns bancos possuem linguagem de consulta própria.
· O Cassandra possui o CQL (Cassandra query Language) muito semelhante ao SQL.
-Não possui todos os recursos, por exemplo subconsultas ou junções não são suportadas.
ONDE UTILIZAR?
- Registros de eventos (log)
· São também boas escolhas para o armazenamento de logs;
· Cada aplicativo pode gravar seus eventos no banco com sua própria chave de linha;
-Sistema de gerenciamento de conteúdo (CMS) – Blogs:
· Podem ser armazenadas entradas de blogs como tags, categorias, trackbacks em diferentes colunas;
· Comentários podem ficar na mesma linha ou em keyspace diferente;
· Os usuários dos blogs podem ser colocados em diferentes famílias de colunas.
- analise de acesso
· Em muito aplicativos web é necessário contar e categorizar visitantes para analise;
· Podemos utilizar famílias de colunas e ter colunas para cada pagina visitada por um determinado usuário.
- Expirar uso
· Devido ao timestamp presente nas colunas do Cassandra é mais simples expirar um uso;
· Por exemplo:
-Aplicativos de testes 
-Mostrar propaganda por um determinado tempo.
· Para isso basta setar o TTL (time to live) das colunas;
· Quando a coluna for excluída o banner pode ser ocultado ou o acesso revogado.
ONDE NÃO UTILIZAR?
· Quando o sistema requer transação ACID;
· Se há necessidade que o banco agregue dados das consultas como SUM ou AVG;
-Isso vai ser feito do lado do cliente, utilizando os dados de todas as linhas;
EXEMPLOS DE SGBDs:
· Cassandra 
· Hbase
· HyperTable
· DynamoDB
BANCO DE DADOS ORIENTADO A DOCUMENTOS:
· Os bancos de dados podem extrair e gerenciar um grande volume de informações;
· Um bom exemplo de informações são os e-mails, que contém algumas informações no seu cabeçalho, e mais informações no seu conteúdo.
· Essas informações podem ser utilizadas para buscas, realização de analises, minerações, dentre outros.
· Esses documentos podem ser XML, JSON, BSON, dentre outros.
-Dados semi estruturados.
· Podem ser vistos como um banco de chave-valor onde o valor pode ser examinado.
· Similar ao chave-valor, mas o valor é um documento 
· São indexados e é oferecido um mecanismo de consulta; 
· Pode ser localizado pelo seu ID único ou por qualquer registro que tenham no documento:
- Exemplo: o objeto possui um único identificador e o banco fica responsável por indexar e promover mecanismos de busca.
· Documentos podem ser endereçados por uma chave única:
- Uma string, identificadores, caminho.
· A chave pode ser utilizada para recuperar um documento;
· Os bancos mais recentes permitem fazer muito mais:
-Buscas a partir de conteúdo;
-Linguagem de consulta própria.
· Podem ser utilizados arrays ou documentos internos;
· Não existem campos vazios. Se não está lá é porque não era relevante.
RECURSOS DE CONSULTA:
· Alguns ex de recursos: Visões materializadas ou dinâmicas;
· É possível consultar dados dentro do documento sem ter que recuperar o documento inteiro por sua chave;
- Consultas próximas ao modelo relacional.
· O mongo DB possui uma linguagem de consulta expressiva via JSON que permite a combinação de diversos comandos;
VANTAGENS DE USAR O JSON:
· Flexibilidade, disponibilidade, linguagem de consulta simples e performance.
DESVANTAGEM:
· Perda em consistência (por ter muita “liberdade” na linguagem cada autor fará ao seu gosto e por esse motivo perde a consistência)
ONDE UTILIZAR?
-Registros de eventos (LOG):
· Em uma empresa pode existir diversos aplicativos interessados em registrar eventos;
· O bd de documentos pode funcionar como uma deposito central de dados;
- Sistema de gerenciamento de conteúdo – plataforma de Blog.
· Como os bancos não possuem esquemas, o formato JSON pode servir bem para Blogs;
· Eles poderiam armazenar: comentários, registros, perfis, documentos visualizados, dentre outros.
-Analise web (analytics)
· Podem armazenar dados para anlise em tempo real; 
· Como parte dos documentos podem ser atualizadas, é fácil armazenar visualizações, visitantes, além de adicionar novas métricas.
-comercio eletrônico
· As vezes é necessário haver um esquema flexível para produtos e pedidos;
· Deve ser possível também alterar dados sem refatorações ou migrações de esquemas.
ONDE NÃO UTILIZAR?
- Transações complexas
· Se for necessário realizar transações atômicas em múltiplos documentos esses bancos podem não ser ideais;
· Por outro lado, alguns bancos dão suporte a essas operações, como o RavenDB.
DB baseados em documentos:
MongoDB:
· É um banco livre de esquema orientado a coleções,
· Os dados são agrupados em conjuntos chamados coleções;
· Cada coleção possui um nome único dentro do banco e podem conter diversos documentos 
· Formato especial BSON 
CouchDB
· Servidor de banco de dados de documentos 
· Dados são acessados através de um API RestFul JSON
· Livre de esquema 
· Podem armazenar diversos arquivos 
· Indexável e permite consulta nos dados
· Utiliza Java Script para realizar consultas 
· Os valores podem ser strings, números, datas, listas ordenadas ou mapas.
RavenDB
· .NET
· Prioriza a alta performance
· Armazena qualquer documento 
· JSON
· Utiliza C# para realizar a indexação dos documentos.
OrienteDB
· Escrito em Java 
· As relações entre os dados são representadas como um banco de dados em grafo;
· Tem um sistema de perfis de segurança forte e suporta SQL como linguagem de consulta.
Raptor DB
· Extremamente ágil e pequeno 
· Persiste dados utilizando arvores B+ ou indexação Hash
· Foi projetado para armazenar JSON, mas permite outros tipos de documentos 
BANCO DE DADOS BASEADO EM GRAFOS:
· É a possibilidade de representar relações graficamente
· Não existe uma forma única de desenhar um grafo
-Ex: uma ligação telefônica onde quem liga e quem recebe a ligação são os nós a distância é a aresta
APLICAÇÕES DE GRAFOS:
· Buscar páginas na web
-Vértices são as páginas HTML e as arestas (direcionadas) são os links ligando as paginas
· -Identificar proximidade entre duas paginas quaisquer 
· -Identificar se uma página é acessível a partir de outra 
· -Identificar o numero de links para uma página (grau do vértice)
ROTEAMENTO DE CARGA:
· Vértices são pontos de entrega e as arestas (com peso) são estradas 
· Descobrir a rota de entrega com menor custo 
· Identificar a rota mais rápida 
MODELOS DE GRAFOS:
· Combinação de nós e conexões ocorrem em uma variedade de aplicações;
· Redes físicas: circuitos elétricos, rodovias ou moléculas orgânicas.
· Interações mão físicas: como relações sociais, banco de dados ou o fluxo de controle em um programa de computador.
· Os grafos consistem em um conjunto de vertices e um conjunto de arestas, com uma relação de incidência sobre eles 
· Os vertices e arestas podem ter atributos adicionais como, cor, peso,ou qualquer coisa que seja útil para o problema
DEFINIÇÃO DE GRAFOS:
· Um grafo G=(V,E) consiste em um conjunto de vertices (pontos ou nós) V e um conjunto de arestas (linhas) E 
· Cada aresta tem um ou doirs vertices associados a ela, são os pontos de conexão da aresta.
· Podemos representar as arestas por partes ou vertices (u,v)
BANCO DE DADOS EM GRAFOS:
· Os bancos de dados baseados em brafos permite que além das entidades sejam também armazenados os relacionamentos entre eles 
· Nó – instancia de um objeto
· Aresta – relacionamentos que podem ter propriedades
· As arestas são direcionadas (INCOMING E OUTGOING)
· Existe sempre um nó inicial e um final
· podemos acrescentar relacionamento nas arestas, significando as relações entre os nós 
· uma consulta a um grafo é chamado de percurso 
-os percursos podem ser modificados sem alterar os nós (podemos colocar informações tanto nos nós como nas arestas)
· percorrer um grafo é mais rápido que fazer junções ou outros processamentos.
· Boa parte do “poder” dos bs dos grafos vem dos relacionamentos;
· Devemos modelar com cuidados; adicionar nós é fácil, mas alterar é muito complexo.
RECURSOS DE CONSULTAS:
· Os nós podem ser indexados quando são inseridos ou quando são percorridos;
· Os nós podem ser indexados por suas propriedades 
· Após indexar os nós, podemos pesquisar usando essa propriedade, exemplo: dados um nó com o nome Paulo, podemos consultar o índice da propriedade nome que tenha valor igual à Paulo.
· Percorrer relacionamentos em um nível é fácil, a vantagem desses bancos é percorrer em qualquer profundidade.
· Todo percurso inicia em algum nó 
· Podemos também realizar percursos sob um número restrito de profundidade:
-exemplo: percorrer o relacionamento amigo somente no segundo nível
BANCO DE DADOS DE GRAFOS:
· Após criado o grafo o banco permite consultas nessa rede com base nas operações e consultas projetadas para esse grafo 
· Mais natural que o relacional 
· O trabalho fica na hora de inserir 
-Indicado quando existir mais consultas que inserções 
· O trabalho do banco consiste principalmente em navegar pelas arestas 
ONDE UTILIZAR:
Dados conectados:
· Redes sociais são um exemplo perfeito de onde utilizar 
· Podemos representar além das amizades:
-Funcionários de uma empresa
-Competências
-Onde trabalham
· Qualquer domínio rico em links é apropriado mesmo que esses links sejam em diferentes domínios 
Roteamento, envio e serviço baseado em localização:
· Todo local ou endereço de entrega pode ser um nó 
· Os relacionamentos podem conter propriedades de distancia 
· Pode ser utilizado também para fornecer opções de localidades próximas 
Mecanismos de recomendação:
· Podemos usar para fazer sugestões: “seus amigos gostaram do produto X”
· À medida que o banco aumenta, aumenta também o número de nós disponíveis para fazer recomendações 
· Pode ser utilizado para detectar fraudes em transações baseados em padrões de relacionamentos
Onde utilizar:
· Mais fácil encontrar respostas para consultas 
· Esses bancos são especializados nesse tipo de informação e são ideais para:
- redes sociais 
- preferencias de produto
- regras de aceitabilidade
Onde não utilizar:
· Ao atualizar todas as entidades ou um subconjunto delas:
- todas as entidades precisam ser alteradas com numa propriedade x alterada.
· Alguns bancos tem problemas em trabalhar com muitos dados, especialmente em operações globais 
Exemplos :
· NEO4J
· INFOGRID
· HYPERGRAPH
· INFINITE GRAPH 
· ORIENT DB 
· FLOCK DB
AULA 3: MODELOS BASEADO EM CHAVE-VALOR PARTE I
CONCEITO DE SCHEMALLES OU (SEM ESQUEMA)
Durante um projeto de banco de dados é necessário definir 2 coisas:
1. A estrutura (campos ou atributos) das tabelas.
2. Os tipos de dados para cada um dos atributos.
Dependendo da aplicação alguns desses atributos nem sempre são usados e, em outra situação, a predefinição da estrutura da tabela com os seus atributos nem sempre é tão fácil de ser realizada, pois os dados podem variar muito quanto ao conjunto de atributos que efetivamente serão usados pelos usuários.
Para facilitar a inclusão de registros o modelo chave-valor não exige um esquema pré-definido como nos bancos de dados relacionais. Dessa forma, oferece mais flexibilidade para atender as necessidades das aplicações.
Um exemplo dessa funcionalidade seria incluir todas as postagens de usuários em blogs em sistema de gerenciamento de conteúdo, apresentando grandes variações no conteúdo. Assim, podemos definir schemalles como o banco de dados que não possui a estrutura de suas tabelas de forma fixa e estabelecida.
De modo a manter um padrão de formato com amplo conhecimento, esse modelo permite o armazenamento de dados no formato JSON, também muito usado em intercambio de dados. Nele, pode-se alterar a estrutura de dados de acordo com a necessidade de aplicação.
Comandos NoSQL para a definição da estrutura do banco de dados:
Ela é uma contribuição (contrib) disponível desde a versão 8.4 (2006) do PostgreSQL. Sua proposta consiste em ser útil para armazenar conjuntos de dados compostos por chaves-valor e que são armazenados em uma única coluna (atributo) de uma tabela conforme a proposta schemaless do banco NoSQL. O tipo do dado usado no armazenamento é um atributo composto e pode utilizar tipos de dados diferentes.
O PostgreSQL possui todos os requisitos de um banco de dados transacional e totalmente compatível com as propriedades ACID 
Suporta views e views materializados, procedimentos armazenados, triggers e outros tipos de objetos comuns a banco de dados relacionais.
Suporta particionamento
Possui controle de concorrência multiversão (MVCC) 
Busca de texto completo 
Indexação com vários tipos de algoritmos (B-tree, GIST, etc)
Permite operações de manutenção de modo online
Operações geoespaciais (PostGIS)
Possui linguagem procedural.
Conectividade com o PostgreeSQL:
· A conexão é feita via redes TCP/IP padrão. Possui um protocolo de transmissão de nome libpq, que também é o nome da biblioteca cliente que o implementa.
· Uma vez estabelecida a conexão, nos comunicamos com o PostgreSQL enviando comandos
· Sua linguem combina declarações em conformidade com o padrão SQL:2008 e comandos de manutenção específicos.
· O SGBDR serve uma instancia a partir de uma única porta TCP/IP.
· O PostgreSQL possui alguns limites gerais de uso em seus dados limitados ao suporte do computador.
· Baseado em álgebra relacional 
Funções REPLACE: https://www.postgresql.org/docs/8.1/functions-string.html
Funções CAST: https://www.postgresql.org/docs/9.2/sql-createcast.html
JSON:
· O JSON é um formato-padrão aberto que consiste em pares de chaves-valor.
· O principal uso do JSON é o intercâmbio de dados entre um servidor e uma aplicação na web.
· De forma diferente da apresentada por outros formatos, o JSON é um formato em texto legível por humanos.
um fator importante para o desempenho dos bancos de dadosNoSQL é Ter suporte de transações diferente do relacional. Por conta de sua simplicidade, são muito usados em aplicações que necessitam de velocidade nas pesquisas. Eles têm um desempenho superior aos relacionais, principalmente quando são usados em operações que necessitam de velocidade nas leituras e gravações de dados, isso devido ao fato de que seu suporte ao processamento não segue o modelo clássico de transações usado nos bancos relacionais, com base nas propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). Ou seja, a velocidade foi o critério primordial para a indicação dos tipos de aplicações mais adequadas para seu uso, assim como suas formas de armazenamento de dados, com um suporte de transações diferente dos relacionais.
AULA 4: 
 JSON (JavaScript Object Notation) tem sido muito utilizado, desde seu lançamento em 2000, em aplicações que necessitam de publicação baseada em texto. Pode-se classificar o JSON como um formato genérico e que usa um número limitado de tipos de dados composto por números, strings, booleanos (true/false), vetores, objetos e nulo
 formato é muito usado para troca dedados entre clientes e servidores web, pois seu antecessor, a linguagem de marcação extensível (XML), quando usado para esse fim, apresenta dificuldade no uso com a linguagem de programação interpretada JavaScript. Dessa forma, os desenvolvedores de aplicações para a web começaram também a preferir o uso do JSON em relação à XML (ELMASRI, 2018). Um dos motivos é que o JSON pode ser usado sem necessitar de um schema (como é o caso da XML), para a disponibilização de pares de valores-chave e listas ordenadas. Hoje, o JSON é o principal formato usado em servidores web. Apesar de criado a partir do JavaScript, ele é suportado nativamente ou por meio de bibliotecas por grande parte das principais linguagens de programação.
Além das vantagens do JSON, seu uso em bancos de dados acrescenta ao conjunto de funcionalidades normalmente presentes nos sistemas gerenciadores de bancos de dados, e permite a manipulação dos dados armazenados em JSON com os comandos da SQL. Dessa forma, uma consulta pode ser executada e exportada em JSON, facilitando o desenvolvimento de aplicações. Isso resultou no suporte nativo ao JSON em bancos de dados como o PostgreSQL e o MySQL.
Para listar uma parte de uma chave como tipo JSON usa-se o operador “->”. Nesse caso,serão listados três nomes de clientes;
Uma observação é que não se pode usar o distinct e order by sobre o campo JSON. Assim, necessita-se transformar para texto com o operador “ ->> ”.
o modelo chave-valor é schemaless
AULA 5:
MODELAGEM DE BANCO DE DADOS ORIENTADO A DOCUMENTOS
· Destacam-se como vantagens desse tipo de banco de dados o suporte a agrupamentos de conjuntos de pares do tipo chave-valor;
Modelo orientado a documentos
Nesse modelo, a base de dados pode ser vista como um repositório de documentos, e esses documentos podem ser representados com estruturas que apresentam grandes diferenças em seus formatos, porém são usadas no mesmo banco de dados.
Assim como o chave-valor, o modelo orientado a documentos não exige um esquema (schema) pré-definido.
O banco de dados orientado a documentos é considerado por usuários como uma evolução do modelo do tipo chave-valor. De uma forma análoga ao modelo relacional (ELMASRI; NAVATHE, 2018), os dados no modelo orientado a documentos são armazenados como coleções de documentos.
No modelo relacional usamos a estrutura baseada em tabelas e registros.
No modelo orientado a documentos, uma coleção pode ser formada por um ou vários documentos.
Os documentos representam as unidades de armazenamento de dados, e esses são representados nos SGBDs como linhas ou registros de uma tabela. Em termos de composição, um documento por ser um item simples ou composto.
Como exemplo, podemos considerar documentos representando listas, documentos simples ou documentos embutidos em outros.
Quanto aos tipos de formatos de arquivos que podem ser usados para o armazenamento de um documento, esses podem ser codificados de formas diferentes, como nos formatos:
· XML (eXtensible Markup Language);
· JSON (JavaScript Object Notation);
· JSONB (usado no PostgreSQL);
· BSON (Binary JSON);
· YAML (YetAnother Markup Language);
· Com textos simples.
Para criar um banco de dados no MongoDB, basta indicar o nome do banco como se ele já existisse. Para isso, digite apenas o comando use e o nome do database:
use aula
Vejamos, então, o exemplo para a coleção pedidos:
db.createCollection("pedidos", {capped:true, size:1310720, max:500} )
Porém, a coleção pode ser criada sem os opcionais, apenas desta forma:
db.createCollection("pedidos" )
Para ver se a coleção foi criada, execute o comando a seguir:
show collections
A operação de copiar e colar no MongoDB Shell é concluída apenas ao clicar com o botão direito do mouse. Outra observação é que, para limpar a tela com os comandos anteriores, basta clicar a combinação de teclas CTRL + L.
Após criados o banco de dados e a coleção, vamos incluir um documento nessa coleção (o que seria semelhante a incluir um registro em uma tabela em um banco de dados relacional). Em nosso exemplo, trata-se do documento de um pedido de um cliente (semelhante ao exemplo apresentado na aula anterior no modelo chave-valor).
db.pedidos.insert (
{ cliente : 'Nei',
produto : 'Produto_1' ,
autor : 'curso NOSQL' ,
qtd : 8 ,
peso: 1,
unidade_medida: 'kg' } )
O banco cria um id_field automaticamente para ser usado como identificador único.
O comando db.collection.find() apresentado a seguir serve para listar todos os documentos de uma coleção. Segue o código para a consulta para a coleção pedidos:
db.pedidos.find()
Para inserir mais de um documento da coleção, usamos o comando a seguir:
db.pedidos.insert([
{ cliente: 'Rui',
produto: 'Produto_2',
autor: 'curso NOSQL',
qtd: 9,
peso: 10,
unidade_medida: 'kg'},
{ cliente: 'Lia',
produto: 'Produto_3',
autor: 'curso NOSQL',
qtd: 15,
peso: 200,
unidade_medida: 'kg'}
])
Ainda no conjunto de comandos do CRUD, caso seja necessário excluir todos os registros de uma coleção, pode-se executar o comando a seguir, onde o nome da coleção é informado no comando:
db.pedidos.remove({})
Para excluir uma coleção completa no banco de dados (estrutura e dados), deve-se executar os comandos a seguir, depois de indicar o banco de dados que deseja excluir:
use aula
db.dropDatabase()
A seguir serão apresentadas consultas simples de seleção na coleção em uso nos exemplos. A primeira consulta tem por objetivo listar os dados do produto de nome Produto_3:
db.pedidos.find( { produto : 'Produto_3' } )
Agora, vamos listar os dados dos produtos com quantidade igual a 9 ou a 15:
db.pedidos.find(
{ qtd : { $in: [9, 15 ] } })
Para listar os documentos com peso maior do que 10 kg, basta executar o comando a seguir, onde $gt significa greater then (maior do que): 
db.pedidos.find( { peso: { $gt: 10 } } )
Como os comparadores são diferentes dos usados no modelo relacional, a seguir é apresentada uma Tabela com a lista completa de operadores de comparação de consultas usados no MongoDB e a forma correspondente em SQL ao lado:
Tabela 2 - Comparação entre operadores de comparação no MongoDB e em SQL relacional de banco de dados e no SGBD MongoDB
	Operador
	Expressão no MongoDB
	Expressão em SQL
	Igual
	db.pedidos.find({peso:{$eq: 10 }})
	where peso = 10
	Menor do que
	db.pedidos.find({peso:{$lt: 10}})
	where peso < 10
	Menor ou igual a
	db.pedidos.find({peso:{$lte: 10}})
	where peso <= 10
	Maior do que
	db.pedidos.find({peso:{$gt: 10}})
	where peso > 10
	Maior ou igual a
	db.pedidos.find({peso:{$gte: 10}})
	where peso >= 10
	Diferente
	db.pedidos.find({peso:{$ne :10}})
	where peso != 10
Para atualizar o valor de um documento, podemos usar o comando apresentado no exemplo a seguir. No caso, alteraremos o valor da chave qtd para 25 onde o nome do produto é igual a Produto_3:
try {
db.pedidos.updateOne(
{ "produto" : "Produto_3" },
{ $set: { "qtd" : 25 } }
);
} catch (e) {
print(e);
}
Para atualizar muitos documentos em uma só operação,devemos usar o comando updtateMany(). Vejamos o exemplo paraalterar o nome do autor do curso para todos os documentos. A Figura 3 apresenta o resultado da aplicação do comando:
try {
db. pedidos.updateMany(
{ autor: "curso NOSQL" },
{ $set: { "autor " : "curso de BD NOSQL" } }
);
} catch (e) {
print(e);
}
ara verificar os valores de uma chave sem repetição, basta usar a opção distinct, assim como na SQL:
db.pedidos.distinct( “autor” )
Para contar a quantidade de documentos de uma coleção, pode-se usar este comando:
db.pedidos.countDocuments({})
Quando for necessário excluir um documento de uma coleção, pode-se usar o comando deleteOne(). No exemplo a seguir, o documento cujo identificador foi passado na consulta, será excluído da coleção:
try {
db. Pedidos.deleteOne( { “_id” : ObjectId(“5f7f89161ef8d02630563a3a”) } );
} catch (e) {
print(e);}
Pode-se apresentar os documentos de uma coleção de forma indentada, assim como foi feito na Aula 4 em relação aos registros com o tipo de dado JSONB. Vejamos como fica o comando para a coleção pedidos.
Db.pedidos.find({}).pretty()É possível consultar os dados e apresentá-los de forma ordenada. Para isso, utiliza-se o método sort() para efetuar a classificação de documentos de uma coleção no MongoDB. Para a determinação da ordem,usa-se os valores 1 ou -1 para a ordem crescente e decrescente, respectivamente. Nos exemplos a seguir, a classificação aplicada aos documentos da coleção pedidos é efetuada na chave cliente de modo ascendente e logo depois de modo decrescente. Os resultados são apresentados da Figura 4.
Db.pedidos.find({} ,{“cliente” : 1 ,_id : 0}).sort({“cliente” : 1})
db.pedidos.find({} ,{“cliente” : 1 ,_id: 0}).sort({“cliente” : -1})
Além dos documentos usados nos exemplos, pode-se ainda definir documentos embutidos, como no caso a seguir,para os dados de um cliente:
--criação da coleção
db.createCollection("clientes", {capped:true, size:1310720, max:500})
--uso da coleção e inclusão de um documento
use clientes
db.clientes.insert(
{
"nome" : "Luís",
"endereco" :
{
"rua" : "Rua A“,
"cidade" : "Rio de Janeiro",
"state" : "RJ"
}
})
--consulta ao document cadastrado
db.clientes.find()
AULA 6:
Modelo de dados agregados
Em termos de modelagem, a principal diferença entre os modelos relacional e orientado a documentos é que a modelagem do primeiro é baseada no modelo entidade-relacionamento(ELMASRI; NAVATHE, 2018),e a modelagem das categorias chave-valor orientadas a documentos e orientadas a colunas seguem o modelo de dados agregados. No modelo relacional, os registros armazenam dados de apenas uma entidade (exceção das tabelas de associação). Na modelagem com agregados, os dados são definidos em unidades e essas unidades são estruturas menos complexas e que facilitam o trabalho em determinadas aplicações.
Para a definição dos agregados deve-se considerar o conjunto de dados que normalmente são acessados pelos usuários e que permitem responder as consultas mais usadas por esses; tudo isso para possibilitar uma forma eficiente de desempenho da aplicação.” Essa ideia surgiu para aplicações com a necessidade de alta performance e sua implementação necessita que o desenvolvedor tenha um profundo conhecimento dos dados, de suas relações com outras coleções e das necessidades de consultas do sistema em desenvolvimento.
 PostgreSQL permite o trabalho como um banco de dados orientado a documentos usando agregações que podem ser aplicadas a partir de tabelas temporárias criadas com o recurso denominado CTE (common tableexpressions). Uma expressão de tabela comum é um conjunto de resultados temporários que pode ser referenciado em qualquer instrução SQL como as operações de manipulação de dados, incluindo SELECT, INSERT, UPDATE ou DELETE. Com esse recurso pode obter as seguintes vantagens: a) a melhoria da legibilidade de consultas complexas —CTEs ajudam a organizar consultas complexas de maneira mais organizada e legível; b) a criação de consultas recursivas que se referem às próprias consultas realizadas anteriormente; podendo ser úteis na realização de consultas em dados organizados de forma hierárquica ou em árvore. Para retornar o conjunto de locações como um conjunto de documentos da coleção de locações de um cliente, usaremos o código a seguir que, além do CTE, usa algumas funções JSONB. São elas a função jsonb_pretty(), que retorna um campo JSON indentado JSON em texto, e a função jsonb_build_object(), que cria um objeto JSON a partir de uma lista de argumentos variados.
O termo “agregado” foi criado no surgimento do projeto orientado a domínios (domain-driven design)(SADALAGE; FOWLER, 2013). O agregado é um conjunto de objetos relacionados e usados para facilitar o desenvolvimento do funcionamento de aplicações em clusters. Isso ocorre porque o agregado pode ser compreendido como uma unidade natural que permite melhor tanto a replicação quanto a fragmentação dos dados. Essa ideia de unidade facilita ainda o trabalho da implementação de software por parte dos desenvolvedores.
Comandos NoSQL para manipulação de dados em modelos de dados agregados de documentos
Apresentaremos a seguir os códigos para esses agregados em MQL, a linguagem de consultas do MongoDB.Iniciando com o comando para a criação do banco de dados controle_pedidos:
use controle_pedidos
Após a criação do banco, são criadas as duas coleções: cliente e pedido, correspondentes aos dois agregados, e depois as coleções são exibidas com o comando show:
db.createCollection("cliente")
db.createCollection("pedido")
show collections
Com a tabela criada, é apresentado a seguir o comando para a inclusão de um registro contendo os dados de um cliente com os seus endereços de cobrança e entrega:
db.cliente.insert({
idcliente : 1 ,
nome : 'Ana' ,
endereco_cobranca : { rua :'A', cidade :'Petrópolis', estado :'RJ', CEP :'20000-000', tipo :'cobrança' } ,
endereco_remessa : [ { nr_endereco_remessa : 1, rua :'B', cidade : 'Rio de Janeiro' , estado : 'RJ', CEP :'25000-000' } ,
{ nr_endereco_remessa : 2, rua :'C', cidade : 'Rio de Janeiro' , estado : 'RJ', CEP :'26000-000' } ]});
Agora, vamos executar os comandos a seguirpara incluir os dados desses pedidos e verificar como ficam estruturados os documentos na coleção pedido:
db.pedido.insert (
{ idcliente : 1,
nr_endereco_remessa :1,
idpedido :1,
data_pedido:newDate("<2020-10-06>"),
item :
[ {idproduto : 10 , nome_produto : 'produto_1',
quantidade_vendida : 10 , preco_venda : 25.50 , nrpagamento : 10 } ,
{idproduto :11 , nome_produto : 'produto_2' ,
quantidade_vendida : 20 , preco_venda : 35.00 , nrpagamento : 15 } ] } ,
{ idcliente : 1 ,
nr_endereco_remessa :2 ,
idpedido :2 ,
data_pedido :newDate("<2020-10-07>"),
item : [ { idproduto : 10 , nome_produto : 'produto_3',
quantidade_vendida : 15 , preco_venda : 5.50 , nrpagamento : 101 } ,
{idproduto :11 , nome_produto : 'produto_4',
quantidade_vendida : 40 , preco_venda : 5.00 , nrpagamento : 150 } ] });
Para verificar o conteúdo das tabelas criadas, pode-se executar os seguintes comandos:
db.cliente.find()
db.pedido.find()
A solução indicada para aplicações que necessitam do conjunto de dados em apenas um agregado é apresentada a seguir:
db.cliente_pedidos.insert (
{ idcliente : 1 ,
nome :'Ana',
endereco_cobranca : { rua : 'A', cidade : 'Petrópolis', estado : 'RJ', CEP : '20000-000' , tipo : 'cobrança' } ,
endereco_remessa : [ { nr_endereco_remessa : 1, rua : 'B', cidade : 'Rio de Janeiro' , estado : 'RJ', CEP :'25000-000' } ,
{ nr_endereco_remessa : 2 , rua :'C' , cidade : 'Rio de Janeiro' , estado : 'RJ', CEP : '26000-000' } ] ,
idpedido :1 ,
data_pedido :newDate("<2020-10-06>") ,
item : [ { idproduto : 10 , nome_produto : 'produto_1' , quantidade_vendida : 10 , preco_venda : 25.50 , nrpagamento : 10 } ,
{ idproduto : 11 , nome_produto : 'produto_2' , quantidade_vendida : 20 , preco_venda : 35.00 , nrpagamento : 15 }
] } ,
{
idpedido :2 ,
data_pedido :newDate("<2020-10-07>") ,
item : [ { idproduto : 10 , nome_produto : 'produto_3' , quantidade_vendida : 15 , preco_venda : 5.50 , nrpagamento : 101 } ,
{ idproduto : 11 , nome_produto : 'produto_4' , quantidade_vendida : 40 , preco_venda : 5.00 , nrpagamento : 150 }
] });
AULA: 7
Modelo de dados NoSQL baseado em colunas – parte I
O Cassandra é, segundo o ranking apresentado no DB-Engines, o mais usado dos SGBDs baseados em colunas, seguido do HBase  e do Microsoft Azure Cosmos DB, o Google BigTable e o Hypertable. Esse tipo de modelo de banco de dados NOSQL é usado por grandes empresas, como Apple, Instagram, McDonald’s, Netflix, Github, Spotify, Uber e Walmart, entre muitas outras.
Segundo dados da página oficial do Cassandra, somente a Apple armazena no Cassandra aproximadamente 10 Petabytes de dados distribuídos em 75.000 nós, ou seja, é um banco de dados usado para suporte de grandes volumes de dados.
O Apache Cassandra é um banco de dados distribuído, descentralizado e do tipo software livre. Foi criado não apenas para o armazenamento de grandes volumes de dados, mas para o processamento de grandes quantidades de dados, já quea existência de aplicações envolvendo grandes quantidades é algo comum na área de bancosde dados.
Modelo colunar
A principal característica do modelo colunar é que os dados são organizados em colunas e uma família de colunas corresponde a uma coleção de linhas semelhantes. O modelo de dados do Cassandra usa o conceito de Keyspace, que é um contêiner ou um agrupamento de dados.
Modelo relacional
No modelo relacional, isso corresponde a um banco de dados formado por um esquema (ou schema), que é um conjunto de tabelas. Lembrando que, em SGBDs relacionais como o PostgreSQL, quando não é definido, o banco de dados cria o esquema public para a organização das tabelas.
No contêiner, uma linha no banco de dados é uma coleção de colunas com uma associação entre elas por uma determinada chave. Essas colunas são armazenadas com base em seus nomes e o nome tem como objetivo a identificação das linhas, ou seja, são usadas como a chave para a pesquisa dos registros.
É próprio para aplicações descentralizadas, sendo ele formado por um conjunto de nós. Com isso, obtém-se mais segurança, pois se elimina os pontos únicos de falha em um sistema distribuído, em que deve ser considerado que os dados são replicados pelos nós, para que seja possível fornecer serviços de banco de dados com alta disponibilidade.
É linearmente escalável, o que na prática apresenta como consequência um aumento da taxa de transferência, de acordo com o aumento do número de nós de um cluster. Além disso, o modelo possui também outro ponto positivo, que é permitir a execução de consultas paralelas.
Vantagens do banco de dados colunar em relação ao modelo relacional
No banco de dados colunar, diferentemente da forma usada na estrutura do banco de dados relacional, os dados são organizados e armazenados em colunas. Essa diferença, embora aparente ser muito simples, é uma característica determinante dos bancos de dados colunares.
O Cassandra não faz uso de transações, como nos bancos de dados relacionais, baseadas nas propriedades ACID
Essas propriedades permitem a aplicação de mecanismos de recuperação ou bloqueio de transações em blocos de comandos, bem como que as transações sejam executadas de forma atômica, isoladas umas das outras e com persistência após a conclusão das operações. Porém, essa é uma escolha e não uma ausência de recurso!
O banco de dados colunar não foi projetado para uso em sistemas que necessitam de controle transacional com as propriedades ACID ou para o uso com consultas envolvendo agregações (operações do tipo groupby), como o uso da função de somatório,tendo em vista a própria estrutura do banco de dados.
Os modelos orientados a colunas, como é característica dos bancos de dados NOSQL, usam o Teorema CAP (do Inglês Consistency – Availability–Partition tolerance) para o controle de consistência.
Quanto às terminologias usadas no modelo relacional e no orientado a colunas, temos as seguintes equivalências:
Uma instância de bancos de dados no relacional corresponde a um cluster no colunar.y
A database/schema corresponde a um keyspace.
Uma tabela corresponde a uma família de colunas.
Uma linha é uma linha em ambos; uma coluna no relacional tem os mesmos tipos de dados e é igual para todas as linhas;já no colunar, as colunas podem ser diferentes ao longo das linhas.
Comandos NOSQL para a definição da estrutura do banco de dados
Datastaxem sua versão Community, sem usar a interface gráfica, ou seja, trabalharemos em linha de comando com o Cassandra Query Language Shell (CQLSH) para ter um foco maior nos comandos e não nos recursos da interface.
Uma das características marcantes dos bancos NOSQL é que eles não são limitados ao uso da SQL, ou seja, possuem uma linguagem própria para a manipulação de dados. A linguagem do Cassandra é a CQL – Cassandra Query Language, que suporta comandos do tipo SQL próprios para o modelo colunar.
Primeiro, temos que criar um keyspace, que é um contêiner de dados no Cassandra. Ele desempenha o mesmo papel de um database em SGBD relacional. Crie um keyspace em um cluster de avaliação de nó único:
CREATE KEYSPACE Aula
WITH replication = {'class':'SimpleStrategy','replication_factor' : 1 };
No comando, há a indicação da quantidade de réplicas, bem como a determinação de quantas cópias dos dados são mantidas em um determinado datacenter. Essa configuração necessita de um estudo mais aprofundado, pois afeta a consistência da aplicação, a disponibilidade e a performance como um todo.
Em nossa introdução ao banco de dados colunar no Cassandra, utilizaremos a configuração padrão indicada para avaliação do banco de dados e para ambientes de desenvolvimento e de teste, considerando um datacenter único.
Depois de criado o keyspace, podemos usar o comando abaixo:
DESCRIBE keyspaces;
Com o comando Use, podemos identificar o keyspace a ser usado na sessão atual pelo cliente. Depois de definido o keyspace, todos os comandos seguintesaplicados nas tabelas serão realizados no ambiente desse keyspace, a não ser que seja especificado outro keyspace ou até o momento do encerramento da conexão do cliente. Para tal, usar o comando (observe o uso de ponto e vírgula no fim de cada comando):
USE aula;
Podemos verificar a estrutura do keyspace criado pelo comando apresentando a estrutura logo abaixo do comando:
DESCRIBE aula ;
CREATE KEYSPACE aula WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}AND durable_writes = true ;
A propriedade durable_writes = true significa que os comandos de manipulação de dados escreverão no commit log antes de escreverem no keyspace, garantindo a durabilidade (persistência) do resultado. O valor default é true, que é mandatório no caso de class = SimpleStrategy.
Caso necessário, pode-se destruir um keyspace com o comando: 
DROP keyspaceaula;
Existe a possibilidade de alterar as propriedades de um keyspace com o comando ALTER KEYSPACE seguindo a sintaxe:
ALTER KEYSPACE <keyspace name> WITH <properties> AND <properties> ;
Tipos de dados que podem ser utilizados neste banco de dados:
Os tipos estão ordenados alfabeticamente:
	Nome do tipo de dado
	Tipo de dado
	Descrição
	ascii
	Cadeias de caracteres
	Usado para a representação de uma cadeia de caracteres do tipo ASCII
	bigint
	inteiro longo
	Indicado para uso com inteiros longos, utiliza 64-bits para armazenamento
	Blob
	Blobs
	Usado para binary large objects
	boolean
	Booleanos
	Usado para valores verdadeiro ou falso
	counter
	Inteiros
	Usado para representar uma coluna numerada
	date
	Cadeias de caracteres
	As datas são cadeias de caracteres seguindo o modelo (yyyy-mm-dd)
	decimal
	inteiros, decimais
	Usado para a representação de números decimais de precisão variável
	double
	Decimais
	Usado para a representação de números decimais de precisão variável com 64 bits
	float
	Decimais
	Usado para a representação de números decimais de precisão variável com 32 bits
	Inet
	Cadeias de caracteres
	Usado para a representação de um endereço IP, IPv4 ou IPv6
	Int
	Inteiros
	Indicado para uso com inteiros, utiliza 32-bits para armazenamento
	smallint
	Inteiros
	Indicado para uso com inteiros curtos, utiliza 16-bits ou 2 bytes para armazenamento
	Text
	Cadeias de caracteres
	Usado para a representação de cadeias de caracteres na codificação UTF8
	time
	Cadeias de caracteres
	Os valores são usados para a representação de números inteiros de 64 bits com a precisão de nanossegundos. Os valores são representados como cadeias de caracteres, como por exemplo 14:40:20,123
	timestamp
	Cadeias de caracteres
	Usado para a representação de um campo do tipo data/hora
	timeuuid
	UUID
	O Cassandra possui várias funções para o uso de dados do tipo timestamp representados como UUID
	tinyint
	Inteiros
	Indicado para uso com inteiros pequenos, utiliza 8-bits ou 1 byte para armazenamento
	Uuid
	UUID
	Universally Unique Identifier
	varchar
	Cadeias de caracteres
	Usado para a representação de um campo do tipo cadeia de caracteres na codificação UTF8
	varint
	Inteiros
	Usado para a representação de um campo do tipo inteiro sem a definição do tamanho
	List
	Cadeias de caracteres
	Uma lista é umacoleção de um ou mais elementos com uma ordenação definida
	Map
	Cadeias de caracteres
	Um mapaéuma coleçãode pares do tipo chave-valor
	Set
	Cadeias de caracteres
	Um conjunto é uma coleção de um ou vários elementos que formam um conjunto (set)
Além dos tipos de dados apresentados, os usuários ainda têm a facilidade de criar seus próprios tipos de dados. A seguir são apresentados os comandos que podem ser usados para a criação e alteração dos tipos de dados definidos pelo usuário. São eles:
1
CREATE TYPE
Usado para a criação de um tipo de dados definido pelo usuário..
2
ALTER TYPE
Usado para a alteração de um tipo de dados definido pelo usuário.
3
DROP TYPE
Usado para a exclusão de um tipo de dados definido pelo usuário.
4
DESCRIBE TYPE
Usado para a descrição de um tipo de dado específico dos definidos pelo usuário.
5
DESCRIBE TYPES
Usado para a descrição dos tipos de dados definidos pelo usuário.
Depois de definido o keyspace e do conhecimento dos tipos de dados possíveis de serem usados no Cassandra, verificaremos exemplos de comandos para criar uma família de colunas no banco de dados, sendo essa a mais importante unidade de armazenamento usada no banco de dados. Observe que a CQL é semelhante à SQL:
CREATE TABLE cliente (
codigouuid primary key ,
nomevarchar ,
cidadevarchar ) ;
Convém ressaltar que, no Cassandra, uma família de colunas é o mesmo que uma tabela, assim o comando poderia ter sido escrito da seguinte maneira:
CREATE COLUMNFAMILY cliente2 (
codigouuid primary key ,
nomevarchar ,
cidadevarchar ) ;
Aproveitaremos esse segundo código que criou a família de colunas para apresentar o comando para excluir uma tabela do keyspace; esse comando é semelhante ao usado na SQL do banco de dados relacional:
DROP COLUMNFAMILY cliente2 ;
Para apagar uma tabela, usaremos o mesmo comando da SQL; no caso, não precisamos executar, pois vamos usar a tabela cliente nos exemplos:
DROP TABLE cliente ;
No caso de alguma alteração ser necessária na estrutura da tabela, devemos usar o comando ALTER TABLE. Vejamos o exemplo para acrescentar um atributo do tipo map na tabela cliente:
ALTER TABLE cliente ADD fone map< text, text> ;
Para incluir um registro na tabela cliente, podemos usar o comando que contém a função uuid(). Execute os dois comandos INSERT a seguir:
INSERT INTO cliente(codigo, nome, cidade, fone)
VALUES (uuid(), 'Ana', 'Rio de Janeiro', {'21' : '1111-2222'});
INSERT INTO cliente(codigo, nome, cidade, fone)
VALUES (uuid(), 'Lia', 'Minas Gerais', {'21' : '1111-2222' , '31' : '2222-3333'});
Com um SELECT simples, podemos ver o resultado:
--------------------------------------+----------------+----------------------------------------+------
309c705e-cc18-434f-88ee-a1a208f43f1f | Minas Gerais | {'21': '1111-2222', '31': '2222-3333'} |Lia
36720507-be52-4a64-9158-1b85c4e3115b | Rio de Janeiro |{'21': '1111-2222'} |Ana
O valor do campo código (tipo UUID) é aleatório e pode ser diferente do criado pelo seu banco.
O código a seguir serve para fazer uma atualização da tabela cliente. No caso, será retirado um par chave-valor do atributo fone, que é do tipo map::
UPDATE cliente SET fone = fone - {'21'}
WHERE codigo =309c705e-cc18-434f-88ee-a1a208f43f1f ;
Outro atributo composto usado no Cassandra é o tipo SET. No exemplo a seguir, será alterada a tabela cliente e acrescentado um atributo para o armazenamento dos contatos de um cliente. Logo, será realizada a atualização dos valores:
ALTER TABLE cliente ADD contatos set<text> ;
UPDATE cliente SET contatos = { 'Rui', 'Nei' }
WHERE codigo =309c705e-cc18-434f-88ee-a1a208f43f1f;
AULA: 8
MODELO DE DADOS BASEADO EM COLUNAS PARTE II
Modelo relacional
Nesse modelo, normalmente, começamos a criação do banco de dados com o projeto e depois avaliamos as consultas que podem ser respondidas pelo modelo.
Modelo orientado a colunas
O início do projeto é feito com o modelo de consultas e não com o modelo de dados, possibilitando que os dados sejam organizados para responder a essas consultas de forma eficiente.
Comandos CQL para manipulação de dados: insert, update e delete
A ideia é que, após a identificação das consultas principais ao uso do banco de dados, sejam criadas as tabelas necessárias para dar suporte a elas. Assim, será criada uma tabela para atender a cada consulta identificada. Dessa forma, o aumento do desempenho justificará a criação de múltiplas tabelas e, é claro, com redundância de dados.
Para melhor entendimento dessa visão diferenciada da modelagem do banco de dados, vamos criar um exemplo. Assim, primeiramente vamos criar uma tabela geral com os dados dos clientes. Seu código ficaria assim:
CREATE TABLE cliente (
codigo uuid primary key ,
nome varchar ,
login varchar ,
email varchar ,
cidade varchar ) ;
Agora, considerando como requisito de dados a recuperação dos clientes por cidades, será apresentado em seguida o código para a criação de uma tabela com o objetivo de atender a essa demanda da aplicação. Vejamos:
CREATE TABLE clientes_por_cidade (
login varchar PRIMARY KEY,
cidade varchar ) ;
Para a inclusão de registros na tabela clientes_por_cidade, pode-se usar também o comando INSERT que avalia a existência de registros com o mesmo valor no campo criado como chave primária. Se o valor não existir, o registro será incluído e uma mensagem de confirmação indicará o sucesso na operação com o retorno True, como abaixo:
INSERT INTO clientes_por_cidade ( login, cidade ) VALUES ( 'ana', 'Rio de Janeiro' )
IF NOT EXISTS ;
[applied]
-----------
True
No caso da existência de um registro que já contenha o valor da chave primária na tabela, a mensagem de retorno indicará um False e os dados não inseridos.
[applied] | login | cidade
------------+---------+----------------
False | ana | Rio de Janeiro
Se fosse identificada a necessidade de consultar os clientes por meio do atributo e-mail, outra tabela poderia ser criada considerando o atendimento a essa demanda. O código é apresentado a seguir:
CREATE TABLE clientes_por_ email ( email varchar PRIMARY KEY, login varchar ) ;
Além da diferença entre termos de modelagem de dados, um outro conceito fundamental para o uso de um banco de dados de colunas é o conceito de partição de dados (SADALAGE; FOWLER, 2013). Os sistemas distribuídos armazenam os dados recebidos em partições.
Todas as operações comuns nesse tipo de sistema, como a replicação, a distribuição e a indexação de dados, são possíveis de serem implementadas apenas quando há a definição de partição(ões), ou seja, podemos considerar como uma unidade de trabalho.
No Cassandra, a chave primária pode ser composta por duas chaves consideradas especiais:
· Chave de partição (partition key); e
· Chave de armazenamento em clusters (clustering columns), de uma forma opcional.
· A chave de partição tem por objetivo facilitar o controle de distribuição dos dados de modo uniforme pelos clusters.
· O particionamento de dados faz uso de um atributo da tabela para ser configurado como a "chave de partição", permitindo o agrupamento dos dados em partições distintas. O tamanho máximo de uma partição no Cassandra não deve ultrapassar o valor de 100 MB e, de uma forma ideal, deve ser inferior a 10 MB.
· Já a outra chave, que é a chave de armazenamento em clusters, também conhecida como chave de colunas de armazenamento em clusters, tem como tarefa facilitar o controle do armazenamento em clusters.
· Com essa segunda chave, é possível obter uma melhor organização dos dados de uma partição possibilitando a criação de consultas eficientes. Para exemplificar, vamos criar uma tabela para o controle de logs de um sistema de acesso dos usuários de filiais.
· A tabela log faz uso do atributo de tipo timeuuid (universal unique identifier), uma variante de identificador único universal que inclui informações de tempo.
· CREATE TABLE log (
· filial varchar,
· data timestamp ,
· datahora timeuuid ,
· login varchar ,
· PRIMARY KEY ( ( filial , data ), datahora ) ) ;
· De forma resumida, podemos destacar as limitações impostas na linguagem de consulta Cassandra (CQL)da seguinte forma:
· a) não tem suporte para consultas de agregação como, por exemplo, as que usam função como o valor máximo, o mínimo e a média (max, min e avg);
· b) não tem suporte para consultas a partir de parte de cadeias de caracteres;
· c) não tem suporte para agrupamento;
· d) não tem suporte para a construção e uso de junções;
· e) não suporta consultas com o comparador OR;
· f) não tem suporte para consultas de união e interseção;
· g) os campos comuns da tabela não podem ser filtrados sem criar o índice secundário e, por fim;
· h) consultas com operadores de comparação maior ( > ) e menor que ( < ) só podem ser executadas na chave de armazenamento em clusters.
O Cassandra permite criar consultas de agregação desde que o usuário indique com um allow filtering no final da consulta. A construção de consultas envolvendo agregações necessita do acréscimo de uma permissão de habilitação de filtragem. Isso é feito na própria consulta, no final dela. O Cassandra alerta que isso pode causar uma performance imprevisível.
AULA:9
MODELOS DE DADOS NOSQL BASEADO EM GRAFOS PARTE I
houve a necessidade da criação de um modelo de dados mais flexível (entre outras importantes características) para atender às aplicações mais recentes. Nesse contexto, surgiu o modelo de dados baseado em grafos.
Os bancos de dados baseados em grafos surgiram ainda nos anos 1980 e 1990, juntamente com o modelo orientado a objetos, porém, logo perdeu espaço para os bancos de dados semiestruturados com a linguagem XML (eXtensible Markup Language).
Com o avanço da chamada Web de Dados (ELMASRI; NAVATHE, 2018) e a popularização das redes sociais, ressurgiu o interesse nos sistemas gerenciadores de banco de dados (SGBDs) não relacionais. Para o estudo desse modelo, iremos usar o SGBD Neo4J. Lançado em 2007, hoje é o mais usado dos SGBDs que seguem o modelo de dados em grafos.
Banco de dados baseado em grafos
Características
O banco de dados é composto por dois tipos de componentes principais, como em toda estrutura em grafos: Os vértices e as arestas.
Vértices
Os vértices são também chamados de nós. Os nós são usados para a representação de entidades, de forma semelhante ao conceito de entidades no modelo relacional, o que seria a representação das tabelas. Assim, como exemplos de entidades, podemos citar as pessoas e lugares.
Os nós são as ocorrências das entidades no gráfico, e podem conter qualquer número de atributos (formados por pares de chave-valor), chamados de propriedades. Esses nós podem ser sinalizados com marcadores ou cores que representam suas diferentes funções no domínio do projeto. Os nós e relações suportam propriedades, um par de valores-chave onde os dados serão armazenados.
Arestas
As arestas são conexões entre os nós e representam os relacionamentos entre os vértices ligados por essas arestas. A Figura 1 indica um exemplo para o relacionamento de trabalho e de interesses entre duas pessoas em uma companhia. Mesmo com esse exemplo simples, podemos identificar o nó, a aresta e as propriedades dos nós.
Para facilitar a identificação das entidades, cores são usadas para cada uma delas.
Relacionamento entre nós
Como no modelo de entidades e relacionamentos, estes são nomeados de modo a traduzir a semântica da ligação entre duas entidades, como, por exemplo, o empregado trabalha_para a empresa. Os relacionamentos se apresentam sempre únicos em direção, tipo, com um nó inicial e um final.
Assim como no caso dos nós, os relacionamentos têm também uma lista de propriedades. Essas propriedades podem indicar tipos como um valor temporal (como no exemplo, desde: 2015 ou pesos, valores, distâncias, classificações ou valores de intensidade.
Entre as principais características do modelo, pode-se destacar a performance do banco de dados, tendo em vista o modo de acesso nativo aos nós e relacionamentos, permitindo percorrer rapidamente milhares de nós por segundo.
Para isso, o SGBD faz uso do poder da computação distribuída. Dois nós podem compartilhar qualquer número de relacionamentos sem prejudicar o desempenho do banco de dados.
Vantagens e tipos de aplicações
Até aqui, foi visto que a estrutura fundamental do modelo de banco de dados em grafos é chamada de "relacionamento de nós". Essa estrutura é muito adequada quando a aplicação necessita lidar com dados altamente conectados. Apesar de serem armazenados em uma direção pré-determinada, os relacionamentos podem ser sempre navegados de um modo eficiente em qualquer direção.
Esse modelo de dados facilita a navegação pelos relacionamentos. Vale também destacar que esse tipo de armazenamento e navegação não é eficiente em SGBDs relacionais devido às estruturas de tabelas rígidas e a dificuldade de seguir as conexões entre os dados, a não ser por operações de junção, custosas em tempo de execução.
Como exemplos de aplicações indicadas para serem desenvolvidas com o modelo de grafos, 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.
Um outro exemplo que pode ser estendido para representar a riqueza de possibilidades de relacionamento é a aplicação do modelo nas redes sociais Nessa aplicação, os vértices serão os usuários e as arestas podem indicar o relacionamento dos seguidores da rede.
Normalmente, o banco de dados baseado em grafos será o mais indicado para aplicações científicas e técnicas.
Um exemplo de uso é o voltado para o tratamento de aplicações complexas, como as que visam o mapeamento para perfuração de campos de petróleo em tempo real, as quais podem se beneficiar do uso do modelo de grafos.
Nesse tipo de aplicações, muitas variáveis são usadas, como, por exemplo, o valor da temperatura, a salinidade do mar da região, assim como as propriedades biológicas, químicas e físicas.
Os modelos de doenças e interações genéticas, bem como pesquisas de padrões gráficos de proteínas para encontrar outros genes que podem estar associados a uma determinada doença, são exemplos de aplicações científicas que podem ser desenvolvidas em grafos.
Fazendo uso de um modelo baseado em uma plataforma apoiada na computação distribuída, ao invés de um ambiente relacional, aplicações complexas podem ser executadas em menos tempo.
Para encerrar, um outro exemplo é o de uma aplicação para trabalhar com o cruzamento de dados distintos, mas relacionados, permitindo analisar melhor as possiblidades de uso.
Por exemplo, a verificação de tipos de relacionamentos entre assuntos atuais nas redes sociais e a procura por produtos relacionados e o consequente aumento das vendas desses determinados produtos; ou, ainda, as preferências de produtos baseadas em círculos de amizades, são aplicações típicas dos chamados sistemas de recomendação.
Para o estudo do banco de dados baseados em grafos, usaremos o SGBD Neo4J. O software é um projeto de código aberto, licenciado sob a licença pública GNU. O Neo4J tem suporte de transações ACID (Atomicidade, Consistência, Isolamento e Durabilidade) e tem também como característica a alta disponibilidade por conta do funcionamento em computação distribuída.