Modelagem de dados com MongoDB

Nos últimos anos vem se falado muito sobre os bancos de dados NoSQL e de como eles podem ser eficientes com o armazenamento de grandes volumes de dados pela facilidade de escalabilidade e a velocidade na recuperação de dados. Esses bancos têm objetivos distintos e estão em diferentes classificações tais como: pares chave-valor, orientados à coluna, orientados a grafos ou ainda orientados a documentos.

O MongoDB, que pertence à classificação de banco orientado a documento, é o que vem tendo uma maior adoção pela comunidade NoSQL. Seu desenvolvimento foi realizado pela empresa norte americana 10Gen sediada em Nova Iorque - USA, tendo seu código escrito em C++. Provendo o armazenamento dos documentos no formato JSON, assim como na maioria dos bancos de dados NoSQL, o MongoDB tem uma arquitetura schemaless, assim não sendo necessários se preocupar com a definição de schema, como tipo de dados, nome de colunas ou relacionamento entre as tabelas. O MongoDB e os demais bancos NoSQL não oferecem suporte a instruções SQL, entretanto, ele oferece suporte a consultas a documentos usando uma linguagem específica para pesquisa que é quase tão poderoso quanto o SQL. Suas consultas, além de poderosas, são facilmente convertidas às tradicionais SQL, fazendo com que a transição de um banco relacional para o MongoDB seja melhor assimilada.

Banco de dados orientado a documentos

Os bancos de dados orientados a documentos são bem diferentes dos tradicionais, onde o armazenamento é feito em um conjunto definido de colunas. Em vez disso, os dados são armazenados em documentos previamente definidos, tendo como características o armazenamento de estruturas autocontidas e auto descritivas. Outra característica é que as coleções não possuem um relacionamento explícito entre outras coleções, ferindo os princípios da normalização.

Outra diferença fundamental é que bancos de dados orientados a documentos incentivam a redundância de dados, evitando a criação de tabelas relacionais para armazenar dados que serão reutilizados, como uma tabela de tags na modelagem de uma estrutura para armazenar posts. Ao invés de se criar uma tabela de tags que terá seu id relacionado com os posts, essas tags são colocadas diretamente na coleção do post, realizando agregações de dados em uma única estrutura.

Os bancos orientados a documentos, diferente dos tradicionais que são compostos por uma estrutura contendo tabela, linha e coluna, são representados por estruturas definidas como coleção-documento, na qual uma coleção pode ser a representação de uma tabela e é nela que ocorre o armazenamento dos documentos. Em uma mesma coleção pode existir documentos com diferentes representações. Ao contrário das tecnologias relacionais que possuem uma visão horizontal da tabela, pode-se dizer que a visão do banco de dados orientado a documentos é vertical, como pode ser observado na Listagem 1.

Listagem 1. Coleção Pessoa X Tabela Pessoa.

COLECAO PESSOA
  {
        nome : “Gutierry”
        sobrenome : “Pereira”
        email: “GutierryDsn@hotmail.com”
  }
  {
        nome : “Amanda”
        sobrenome : “vitor”
        telefone : (21)9999-1010
  }
   
  TABELA PESSOA
  +-------------+-----------+-----------------------------+----------------------+
  | Gutierry    | Pereira   | GutierryDsn@hotmail.com     | Null                 |
  | Amanda      | Vitor     | Null                        | (21)9999-1010        |
  +-------------+-----------+-----------------------------+----------------------+

A partir dessa listagem podemos observar uma série de diferenças entre as duas estruturas. Além da forma de visão, observem que no segundo documento da coleção de pessoa, além de não conter o atributo email, apresenta um atributo a mais, sendo ele o telefone. Em uma tabela relacional, é necessário definir a coluna email e telefone, que será ...