Olá, dev! Seja bem-vindo ao Dia 09 da sua preparação para a certificação MongoDB Associate Developer. Hoje abordaremos a filosofia de modelagem no MongoDB — um dos pilares mais cobrados na prova e essenciais para a arquitetura de sistemas de alta performance.
1. A Regra Fundamental da Modelagem NoSQL
Ao contrário dos bancos relacionais, que visam a normalização de dados (3NF) para evitar redundância, no MongoDB a modelagem é orientada pelos padrões de acesso da aplicação (Data Access Patterns).
2. Embedding (Denormalização) vs. Referencing (Normalização)
A. Embutir Dados (Embedding / Nested Documents)
Significa armazenar entidades relacionadas como subdocumentos ou arrays dentro do mesmo documento pai.
- Vantagens: Excelente performance de leitura em operação única (sem necessidade de `$lookup`), atomicidade de escrita no documento inteiro.
- Quando Usar: Relacionamentos "contido em", cardinalidade de um-para-poucos (1:Few), dados estáticos ou acessados simultaneamente.
- Risco: Ocorrência de Arrays Ilimitados (Unbounded Arrays), que podem fazer o documento exceder o limite de 16 MB BSON.
B. Referenciar Dados (Referencing / Normalization)
Significa armazenar as entidades em coleções distintas e vinculá-las utilizando identificadores (`_id`).
- Vantagens: Impede o estouro do limite de 16 MB, evita duplicação de dados altamente mutáveis de grande porte.
- Quando Usar: Cardinalidades grandes (1:Many, 1:Squillions), relacionamentos Muitos-para-Muitos (N:M) ou quando as entidades são lidas de forma independente na maioria das vezes.
- Desvantagem: Exige múltiplas consultas do cliente ou o uso do estágio `$lookup`.
3. Mapeando Cardinalidades de Relacionamentos
1. Um-para-Um (1:1)
Exemplo: Usuario e PerfilConfiguracao.
Estratégia Recomendada: Embutir por padrão. Separe em coleções distintas apenas por motivos de segurança (ex: dados sensíveis) ou se o subdocumento for extremamente grande e raramente lido.
2. Um-para-Poucos (1:Few)
Exemplo: Pessoa e Enderecos (uma pessoa possui 2 ou 3 endereços).
Estratégia Recomendada: Embutir um array de subdocumentos no documento principal.
3. Um-para-Muitos (1:Many)
Exemplo: Produto e Avaliacoes (um produto tem centenas de avaliações).
Estratégia Recomendada: Referenciar no lado N (Parent Reference) armazenando o produto_id em cada documento de avaliação, ou usar o Padrão Subset (Subset Pattern).
4. Um-para-Milhões (1:Squillions)
Exemplo: ServidorIoT e LogsDeEventos (milhões de registros por dia).
Estratégia Recomendada: Usar estritamente Parent Reference (o log guarda o servidor_id). Nunca armazene um array de IDs de logs dentro do documento do servidor!
5. Muitos-para-Muitos (N:M)
Exemplo: Estudantes e Cursos.
Estratégia Recomendada: Guardar um array de referências ([ObjectId]) no lado que realiza a consulta mais frequente, ou em ambos os lados (Two-Way Referencing).
4. Tipos de Referenciação
// 1. Child Reference (O pai armazena array de IDs dos filhos) - Apenas se N for pequeno
// Documento na coleção 'livros'
{
_id: ObjectId("60a..."),
titulo: "MongoDB Guide",
capitulos: [ ObjectId("60b1..."), ObjectId("60b2...") ]
}
// 2. Parent Reference (O filho guarda o ID do pai) - Obrigatório para 1:Many e 1:Squillions
// Documento na coleção 'logs'
{
_id: ObjectId("70c..."),
mensagem: "CPU Overheat",
servidorId: ObjectId("60a...")
}5. Questões no Estilo Exame de Certificação
Questão 1: Você está projetando o banco de dados para uma plataforma de e-commerce. Cada pedido pode conter de 1 a 10 itens. Como os itens do pedido devem ser estruturados em relação ao pedido para obter a melhor performance de leitura e gravação atômica?
A) Criar uma coleção separada de itens e guardar o pedido_id em cada item.
B) Embutir os itens como um array de subdocumentos dentro do próprio documento de pedido.
C) Criar uma tabela de junção N:M entre pedidos e itens.
D) Armazenar os itens como arquivos binários usando o GridFS.
Resposta Correta: B. Como a cardinalidade é baixa (1 a 10 itens) e os itens são sempre lidos e gravados junto com o pedido, o embedding em um array é a escolha ideal.
Questão 2: Um sistema de telemetria de veículos recebe cerca de 50.000 medições de GPS por dia para cada veículo. Qual é a estratégia de modelagem correta para evitar estourar o limite de 16 MB por documento?
A) Embutir todas as medições em um array chamado historicoGPS dentro do documento do veículo.
B) Armazenar cada medição como um documento separado na coleção telemetria contendo o veiculo_id.
C) Aumentar o limite do documento BSON do veículo configurando o `mongosh`.
D) Criar um índice composto no array de medições.
Resposta Correta: B. Para relacionamentos do tipo 1:Squillions, deve-se utilizar a referência do pai (Parent Reference) em documentos separados para evitar o problema de arrays ilimitados.