# Rascunho\_Introduction\_referenciar\_corretamente

Os bancos de dados NoSQL oferecem algumas funcionalidades a mais que os bancos de dados relacionais tradicionais.

Neste capítulo introdutório faremos uma comparação de uso dos NoSQL SGBDs em comparação com os SGBDs relacionais.

### Sistemas de Gerenciamento de bancos de dados

Os SGBDs são espaços logicamente modelados para armazenar todos os tipos de informação. Cada banco de dados possui uma estrutura na qual os dados são gerenciados com diversos formatos, tipos e tamanhos. Segundo Navathe

SGBDs NoSQL

Bases de dados relacionais tem sido a escolha padrão de muitos desenvolvedores e administradores para uma ampla variedade de aplicações e razões. apesar de não ser exatamente flexivel, o poder natural

\==============================

Principais diferêncas entre bancos de dados NoSQL e SQL.

|                                | NoSQL                                                                                                                                            | SQL                                                                                                                                                                                                                                                           |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Modelo                         | Não relacional                                                                                                                                   | Relacional                                                                                                                                                                                                                                                    |
|                                | Armazena dados em documentos      JSON, pares de chave/valor,                grandes colunas de armazenamento, ou grafos                         | Armazena dados em tabelas                                                                                                                                                                                                                                     |
| Dados                          | Oferece flexibilidade e registros não precisam armazenar as mesmas        propriedades                                                           | Melhor para soluções onde cada registro tem as mesmas propriedades                                                                                                                                                                                            |
|                                | Novas propriedades podem ser adicionadas sem alterações no esquema   ("on the fly")                                                              | Adicionar uma nova propriedade pode requerer alterações no schema ou até mesmo utilizar campos existentes para armazenar dados novos                                                                                                                          |
|                                | Relacionamentos são frequentemente obtidos por dados desnormalizados e apresentando todos dados por meio de um único objeto em um único registro | Relacionamentos são obtidos em modelos normalizados usando junções e usando-se de referências (chaves primárias e estrangeiras) entre as tabelas                                                                                                              |
|                                | bom para dados aninhados, semi-estruturados e complexos                                                                                          | bom para dados estruturados                                                                                                                                                                                                                                   |
| Esquema                        | Esquemas dinâmicos ou flexíveis                                                                                                                  | Esquemas rígidos/rigorosos                                                                                                                                                                                                                                    |
|                                | Bancos de dados possui um esquema não definido sendo o esquema ditado pela aplicação                                                             | Esquema deve ser gerenciado e mantida a sincronia estrutural entre aplicação e o banco de dados                                                                                                                                                               |
| Transações                     | Transações ACID suportadas por várias soluções (mas não todas)                                                                                   | Suporta transações ACID                                                                                                                                                                                                                                       |
| Consistência e Disponibilidade | Eventualmente forte consistência é suportada dependendo da solução                                                                               | Forte consistência é obrigatória (forçada)                                                                                                                                                                                                                    |
|                                | Consistência, disponibilidade e performance podem ser tratadas para encontrar as necessidades da aplicação. (Teoria de CAP\*)                    | Consistência é priorizada sobre disponibilidade e performance                                                                                                                                                                                                 |
| Performance                    | Performance pode ser maximizada pela redução de consistência, se necessário.                                                                     | A performance do Insert e update são dependentes de quão rápida a escrita é confirmada (committed), visto que forte consistência e requerida. Desempenho pode ser maximizado pelo uso de escalonamento de recursos disponíveis e uso de estruturas na memória |
|                                | Toda informação sobre uma entidade está tipicamente em um único registro, então uma atualização pode acontecer em uma única operação             | Informação sobre uma entidade pode estar espalhada entre muitas tabelas ou linhas, requerendo muitas junções para completar uma atualização ou consulta                                                                                                       |
| Scale                          | Escalamento é tipicamente alcançado horizontalmente com particionamento de dados em vários servidores                                            | Escalonamento é tipicamente alcançado verticalmente com mais recursos do servidor                                                                                                                                                                             |
| Objetos                        | Entidade/Tabela                                                                                                                                  | Coleção                                                                                                                                                                                                                                                       |
|                                | Instâncias da entidade/Linhas/Registros                                                                                                          | Documentos                                                                                                                                                                                                                                                    |
|                                | colunas da tabela/atributos státicos                                                                                                             | atributos flexiveis (em NoSQL são criados de acordo com os dados de modo flexivel). Isto torna possível ter um uma mesma coleção um documento com 10 atributos e outro com 4 atributos por exemplo.                                                           |

Obs: Teoria de CAP\*

Eric Brewer afirma que é impossível em um armazenamento de dados distribuídos simultaneamente fornecer mais de duas das seguintes garantias:

1. Consistência: cada leitura recebe a gravação mais recente ou um erro. &#x20;
2. Disponibilidade: cada pedido recebe uma resposta (sem erro), mas sem garantia de que contém a gravação mais recente.&#x20;
3. Tolerância de partição: o sistema continua a funcionar apesar de um número arbitrário de mensagens sendo descartadas (ou atrasadas) pela rede entre nós.&#x20;

Ou seja num sistema tolerante a falhas é preciso escolher entre consistência e disponibilidade.

### Exemplo de flexibilidade dos bancos NoSQL

Em uma abordagem onde trabalhamos com vários produtos diferentes, é necessário no modelo relacional que tenhamos uma tabela produto com as mesmas características para todos os produtos. Já nos databases NoSQL cada produto pode ter sua características peculiares armazendas sem quaisquer dificuldades ou problemas. Outra característica interessante é que para um mesmo atributo podemos ter domínios diferentes (String para um determinado registro/documento do atributo e integer para outro registro/documento do mesmo atributo), isto poderia ocorrer em situações onde vários fabricantes de produtos são cadastrados e cada um tem seu pŕoprio código, por exemplo. Outro ponto em que os NoSQL divergem dos SQL Relacionais tradicionais é que não é necessário o uso de Joins e restrições de chave primária e estrangeira, pois os dados são tratados de forma diferenciada.

![](https://3138737707-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M4yXbzMgrzLo01mPMKx%2F-M4yXdupwQpnkEoTAli8%2F-M4yXfuY8R4u2cS8eJdI%2Fuser_skill_relational_sql.jpg?generation=1586965966352072\&alt=media)

Figura 1. Relacionamento clássico entre usuários e habilidades (Fonte: Devmedia.com)

![](https://3138737707-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M4yXbzMgrzLo01mPMKx%2F-M4yXdupwQpnkEoTAli8%2F-M4yXfu_joTe1oTbngkC%2Fuser_skill_graph_NoSql.jpg?generation=1586965967204626\&alt=media)

Figura 2. Representação do relacionamento entre usuários e habilidades em um grafo (fonte: Devmedia.com)

![](https://3138737707-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-M4yXbzMgrzLo01mPMKx%2F-M4yXdupwQpnkEoTAli8%2F-M4yXfubA4OGoLE-NilX%2Frelationa_embebd_json.jpg?generation=1586965968205972\&alt=media)

Figura 3. Exemplo de um relacionamento tradicional versus representação NoSQL embutido no formato JSON das entidades Book Album, Jeans e Track (fonte: Devmedia.com).

Observe que cada tipo de produto no formato JSON possui características diferentes details.

É certo que cada tipo de modelagem possui pontos fortes e fracos. Os Modelos NoSQL tem sido bastante utilizados em cenários onde o algoritmo percorre um grafo ou rotina recursiva para chegar até um nível específico de dados dentro de vários documentos, e portanto aplicados em situações de modelagem com dados provenientes de redes sociais, relacionamentos entre pessoas, objetos, situações, eventos, preferências e comportamentos.

## Exemplos de SQL comparados com MongoDB

#### SQL

a) select \* from tabela where nome LIKE '%Nasc%'

b) select \* from usuarios where UsuarioID IN (2,14,16)

c) insert into usuario(login, email) VALUES('sissa', 'jnascimento@gmail.com')

d) update tarefas set Tarefa='Terminar artigo' where Usuario='suissa'

e) delete tarefas where name='suissa'

#### MongoDB

a) $filter = array( 'title' => new MongoRegex('/.Nasc./i') );

b) $filter = array("UsuarioID" => array('$in' => array(2,14,16)));

c) $query = array( 'usuario' => "suissa", 'email' => "jnascimento@gmail.com");

```
$db-&gt;collection-&gt;insert\($this-&gt;query\);
```

d) $db->collection->update(array('Usuario'=> 'suissa'), array('$set' => array('Tarefa' => 'Terminar artigo')));

e) $db->collection->remove(array('Usuario'=> 'suissa'));

```
References:


https://docs.microsoft.com/pt-br/azure/documentdb/documentdb-nosql-vs-sql
http://www.devmedia.com.br/modelagem-sql-x-nosql/29446
https://imasters.com.br/artigo/17308/mongodb/como-utilizar-selects-com-mongodb?trace=1519021197&source=single
```
