Modelagem de dados
Nesta página
- Casos de uso
- Projeto de esquema: diferenças entre bancos de dados relacionais e de documentos
- Planeje seu esquema
- Vincular dados relacionados
- Dados incorporados
- Referências
- Considerações adicionais sobre modelagem de dados
- Duplicação e consistência de dados
- Indexação
- Restrições de hardware
- Atomicidade de documento único
- Saiba mais
Modelagem de dados refere-se à organização de dados dentro de um banco de dados e aos links entre entidades relacionadas. Os dados no MongoDB têm um modelo de esquema flexível, o que significa:
Documentos dentro de uma única collection não são obrigados a ter o mesmo conjunto de campos.
O tipo de dados de um campo pode diferir entre documentos dentro de uma collection.
Geralmente, os documentos de uma collection compartilham uma estrutura semelhante. Para garantir consistência no seu modelo de dados, você pode criar regras de validação de esquema.
Casos de uso
O modelo de dados flexível permite que você organize seus dados para atender às necessidades do seu aplicativo. O MongoDB é um banco de dados de documentos, o que significa que você pode incorporar dados relacionados em campos de objetos e arrays.
Um esquema flexível é útil nos seguintes cenários:
Sua empresa monitora em qual departamento cada funcionário trabalha. Você pode incorporar informações do departamento dentro da collection
employeepara retornar informações relevantes em uma única query.Seu aplicativo de e-commerce mostra as cinco avaliações mais recentes ao exibir um produto. Você pode armazenar as revisões recentes na mesma collection que os dados do produto e armazenar as revisões mais antigas em uma collection separada, pois as revisões mais antigas não são acessadas com tanta frequência.
Sua loja de roupas precisa criar um aplicativo de página única para um catálogo de produtos. Produtos diferentes possuem atributos diferentes e, portanto, usam campos de documento diferentes. No entanto, você pode armazenar todos os produtos na mesma coleção.
Projeto de esquema: diferenças entre bancos de dados relacionais e de documentos
Quando você cria um esquema para um banco de dados de documentos como MongoDB, há algumas diferenças importantes de bancos de dados relacionais a serem consideradas.
Comportamento do Banco de Dados Relacional | Comportamento do Banco de Dados do Documento |
|---|---|
Você deve determinar o esquema de uma tabela antes de inserir os dados. | Seu esquema pode mudar com o tempo conforme as necessidades do seu aplicativo mudam. |
Muitas vezes, você precisa unir dados de várias tabelas diferentes para retornar os dados necessários para seu aplicativo. | O modelo de dados flexível permite que você armazene dados de acordo com a forma como seu aplicativo retorna dados e evite uniões. Evitar participações em várias collections melhora o desempenho e reduz o volume de trabalho do seu departamento. |
Planeje seu esquema
Para garantir que seu modelo de dados tenha uma estrutura lógica e alcance o desempenho ideal, planeje seu esquema antes de usar seu banco de dados em uma escala de produção. Para determinar seu modelo de dados, use o seguinte processo de projeto de esquema:
Vincular dados relacionados
Ao projetar seu modelo de dados no MongoDB, considere a estrutura de seus documentos e as maneiras como seu aplicativo usa dados de entidades relacionadas.
Para vincular dados relacionados, você pode:
Incorpore dados relacionados em um único documento.
Armazene dados relacionados em uma collection separada e acesse-os com uma referência .
Dados incorporados
Documentos incorporados armazenam dados relacionados em uma única estrutura de documento. Um documento pode conter arrays e subdocumentos com dados relacionados. Esses modelos de dados denormalizados permitem que os aplicativos recuperem dados relacionados em uma única operação do banco de dados.
Para muitos casos de uso no MongoDB, o modelo de dados desnormalizado é ideal.
Para saber mais sobre os pontos fortes e fracos da incorporação de documentos, consulte Modelos de dados incorporados.
Referências
As referências armazenam relacionamentos entre dados ao incluir links, chamados de referências, de um documento para outro. Por exemplo, um campo customerId em uma collection orders indica uma referência a um documento em uma collection customers.
Os aplicativos podem resolver essas referências para acessar os dados relacionados. Em termos gerais, estes são modelos de dados normalizados .
Para saber mais sobre os pontos fortes e fracos do uso de referências, consulte Referências.
Considerações adicionais sobre modelagem de dados
Os seguintes fatores podem afetar a forma como você planeja seu modelo de dados.
Duplicação e consistência de dados
Ao incorporar dados relacionados em um único documento, você pode duplicar dados entre duas collections. A duplicação de dados permite que o seu aplicativo consulte informações relacionadas a várias entidades em uma única query, separando logicamente as entidades no seu modelo.
Por exemplo, uma collection products armazena as cinco análises mais recentes em um documento de produto. Essas avaliações também são armazenadas em uma collection reviews , que contém todas as avaliações de produtos. Quando uma nova revisão é escrita, ocorrem as seguintes gravações:
A avaliação é inserida na collection
reviews.A array de avaliações recentes na coleção
productsé atualizada com$pope$push.
Se os dados duplicados não forem atualizados com frequência, o trabalho adicional necessário para manter as duas coleções consistentes será mínimo. No entanto, se os dados duplicados forem atualizados com frequência, usar uma referência para vincular dados relacionados pode ser uma abordagem melhor.
Antes de duplicar dados, considere os seguintes fatores:
Com que frequência os dados duplicados precisam ser atualizados.
O benefício de desempenho das leituras quando os dados são duplicados.
Para saber mais, consulte Identificar dados duplicados.
Indexação
Para melhorar o desempenho das queries que seu aplicativo executa com frequência, crie índices nos campos comumente consultados. À medida que seu aplicativo cresce, monitore o uso do índice da implantação para garantir que os índices ainda estejam dando suporte a consultas relevantes.
Restrições de hardware
Ao projetar o schema, considere o hardware do sistema, especialmente a quantidade de RAM disponível. Larger documentos usam mais RAM, o que pode fazer com que seu aplicativo leia do disk e diminua o performance. Quando possível, projete seu esquema para que somente os campos relevantes sejam retornados pelas consultas. Esta prática garante que o conjunto de trabalho da seu aplicativo não cresça desnecessariamente.
Atomicidade de documento único
No MongoDB, uma operação de escrita é atômica no nível de um único documento, mesmo que a operação modifique vários documentos incorporados em um único documento. Isso significa que, se uma operação de atualização afetar vários subdocumentos, todos esses subdocumentos serão atualizados ou a operação falhará inteiramente e nenhuma atualização ocorrerá.
Um modelo de dados desnormalizado com dados incorporados combina todos os dados relacionados em um único documento, em vez de normalizar vários documentos e collection. Este modelo de dados permite operações atômicas, em contraste com um modelo normalizado onde as operações afetam vários documentos.
Para mais informações, consulte Atomicidade.
Saiba mais
Saiba como estruturar documentos e definir seu esquema no curso Modelagem de dados M320 da Universidade MongoDB.
Para obter mais informações sobre modelagem de dados com o MongoDB, faça o download do Guia de Modernização de Aplicativos MongoDB.
O download inclui os seguintes recursos:
Apresentação sobre a metodologia de modelagem de dados com o MongoDB
Artigo técnico que aborda as melhores práticas e considerações para migrar de um modelo de dados SGBD para o MongoDB
Referenciar o esquema do MongoDB com seu equivalente em SGBD
Scorecard de modernização de aplicativos