Quando iniciamos a modelagem de dados em MongoDB, precisamos obter respostas para perguntas pertinentes na construção dessa modelagem. Isso porque, um bom modelo de dados irá alavancar os recursos do banco de dados, e explorar o seu modelo de documento flexível.
A modelagem de dados com MongoDB difere dos modelos tradicionais, pois não segue a normalização como primeira etapa, a flexibilidade que o MongoDB oferece facilita o mapeamento de documentos para uma entidade ou objeto.
O esquema de modelagem no MongoDB abrange três etapas importantes do processo: carga de trabalho, identificação de relacionamento e padrões de design.
Carga de trabalho: Esse processo identifica dados relevantes, define como devem ser capturados e processados, e visualiza esses dados como um diagrama. Essa representação visual ajuda a identificar componentes de dados, determinar relacionamentos e encontrar a melhor maneira de demonstrá-los.
Relacionamentos, e
Padrões.
Com base nisso, duas perguntas devem guiar nossa modelagem:
Quais são as principais peças de dados, ou entidades armazenadas?
Qual dessas entidades muda a longo prazo?
Quais tipos de operações serão feitas?
IDENTIFICANDO CARGAS DE TRABALHO NO BANCO DE DADOS
Imagine o desenvolvimento de um aplicativo para resumir livros. Nele, os usuários podem criar resumos de livros lidos, detalhando os principais pontos, insights e informações relevantes. Cada resumo pode conter uma síntese do conteúdo, ideias-chave, conclusões e observações pessoais, proporcionando uma visão geral do livro para referência futura ou compartilhamento com outros leitores.
Aqui precisamos:
Dimensionar os dados;
Quantificar as operações, e
Qualificar as operações.
De maneira simplificada, como realizar uma análise da carga de trabalho desta aplicação. E acima, fica evidente que a leitura de resenhas se destaca no exemplo dado. Com isso, vamos aprofundar o detalhamento:
IDENTIFICANDO RELACIONAMENTOS
Agora, precisamos compreender os relacionamentos entre as entidades de dados que compõe nosso modelo. Portanto, existem maneiras em que os objetos se relacionam podendo ser: um para um, um para muitos, muitos para um, ou muitos para muitos. E a conclusão dessa etapa resulta em um modelo lógico para nossos dados. Portanto, precisamos:
Identificar os relacionamentos;
Quantificar os relacionamentos, e
Referenciar ou incorporar.
E por fim, agora, vamos definir se ao construir nosso modelo nós vamos referenciar ou incorporar os dados em um documento só. Aqui, é importante mencionar a regra de ouro da modelagem de dados em MongoDB: O que é usado junto na aplicação, é armazenado junto no banco de dados.
Agora, vamos para as especificações de escolhas entre Referenciar e Incorporar:
Referenciar:
Quando o lado “muitos” é um número enorme;
Para integridade em operações de escrita nos relacionamentos muitos para muitos,
Quando uma parte é usada com frequência, mas a outra não é, e a memória é uma restrição.
Incorporar:
Para a integridade das operações de leitura;
Para integridade de operações de escrita um para um, e um para muitos;
Para dados que são excluídos ou arquivados juntos,
Se não souber, sempre, preferencialmente, incorporar.
IDENTIFICANDO PADRÕES
Os padrões tornam a modelagem de dados mais eficiente. Com os padrões de design, é mais fácil acomodar mudanças nos requisitos e estrutura de aplicativos. Aqui, vou abordar dois padrões, mas existem outros diversos que podem se encaixar nas mais diversas modelagens de dados:
Computed: São computações frequentes que tendem a reduzir o desempenho do banco, por exemplo, se uma resenha recebe uma enorme quantidade de comentários. Com o computed evita a necessidade de consultar todos os comentários cada vez que uma contagem é necessária, assim, a contagem de comentários já está disponível no documento, facilitando o acesso aos dados.
Extended Reference (Referência estendida): É uma técnica em que um documento faz referência a outro, mas não somente uma referência básica, este inclui todas as informações relevantes no próprio documento. Isso contribui para a redução de necessidades de consultas adicionais para buscar informações relacionadas.
CONSTRUINDO NOSSO MODELO
Bom, entendemos que nosso aplicativo serve para que cada usuário fique livre para escrever quantas resenhas desejar dos livros que já tenha lido. Assim, entendemos que podemos ter a coleção de usuários e resenhas.
Podemos entender que um usuário pode escrever pouco, mas também pode ser alguém muito ativo, e, portanto, se encaixa em um para muitos. Assim, o lado muitos seria enorme, sugerindo que a referência seria a melhor das hipóteses.
Vou exemplificar como seria Referenciado:
No caso dos comentários, que se enquadram no modelo de relacionamento 'muitos para um', entendemos que, como a regra de ouro nos diz, ao acessarmos uma resenha, desejamos imediatamente ter acesso aos comentários. Portanto, o ideal seria a incorporação dos comentários das resenhas, na coleção resenhas.
Por fim, conseguimos então criar nosso modelo. O que você achou desse exemplo? Algo que faria diferente?
Espero que tenha esclarecido como funciona os princípios de modelagem do MongoDB.